DEV Community: Ahmed Osama

JavaScript weird type system - Double equal sucks

Ahmed Osama — Sat, 27 Nov 2021 14:58:03 +0000

Wassup mate, hate to say it but it's finally last part of this series, and probably that's the most important part of them all, because we're going to speak about equality finally! so let's get started.

I'll start off by arguing against the most well known quote in programming history -probably-

The double equal operator checks for value only while triple equal operator checks for value and type

I am quite sure you've seen this statement somewhere, even I said it back in the time in some of my courses, but hopefully in this article I can rephrase this wrong understanding, or atleast remove the bluriness off of it. So, let's get into it by first using these operators' real identifiers.

Abstract equality operator

Actually this operator was renamed in the TC39 specs to isLooselyEqual which is -tbh- much more semantic name than abstract, as being loose means more flexibility while comparing types, but what happens during this operation?

The double equal operation can be thought of as a function that goes through some steps or checks, the very first one of them is checking if the types of the arguments are same, guess what happens then, yeah it calls the tripe equal function.

So double equal can become triple equal under some conditions, they're not so different after all, it's all about the behaviour that each one of them deals with the types of the inputs.

Let's make some psuedocode about these two operations, but surely we won't be able to cover all of the cases because some cases need access to memory addreses to compare objects, arrays, functions so we will just have some mockery code.

function doubleEqual(x, y) {
  // Handling the first case that types may be the same
  if (typeof x === typeof y) {
    return tripleEqual(x, y)
  }
}

function tripleEqual(x, y) {
  /* Some implementation */
}

Well what if the types are not equal?

The operation goes through the checks from 2 to 9 and if none of these conditions were met, it returns false as the default return.

Abstract equality - Case 2 and 3

It's quite obvious in case 2 and case 3 if these values -x and y- are undefined or null interchangeably, the operation returns true, as it treats them as if they were non-existing values so it coerces them to the same type for easier comparison.

function doubleEqual(x, y) {
  // previous checks

  // handing case 2 and 3
  // Note that you can separate them into two if statements
  if (
    ((typeof x === 'undefined' ||
      typeof y === 'undefined') &&
      typeof x === 'object' &&
      !x) ||
    (typeof y === 'object' && !y)
  ) {
    return true
  }

  return false // default return
}

This long condition can be represented using the following table

typeof x	typeof y	Result
undefined	undefined	true
undefined	null	true
null	undefined	true
null	null	true

We're simply accepting if both of them are any sort of a combination between the undefined and null types, any other type will not be handled by this case.

Abstract equality - case 4 and 5

Once again, case 4 and 5 handle the cases if they're either string or number so it coerces one to the other.

In case 4, we're checking if x is number and y is a string, if so, we return the result of comparing them but coercing y to number

And in case 5, we're checking if x is string and y is a number, if so, we return the result of comparing them but coercing x to number

function doubleEqual(x, y) {
  // previous checks

  // handling case 4
  if (typeof x === 'number' && typeof y === 'string') {
    return x == Number(y)
  }

  // handling case 5
  if (typeof x === 'string' && typeof y === 'number') {
    return Number(x) == y
  }
}

Once again, let's simplify these two cases in a table form

typeof x	typeof y	Result
number	string	x == Number(y)
string	number	Number(x) == y

Abstract equality - case 6 and 7

In case 6 and 7 we're handling if one of them is a boolean value, but note that booleans are only comparable to numbers, the JSE (JavaScript Engine) is only allowed to coerce the boolean to a number.

Case 6 checks if x is the boolean type, if so it converts it to number first and then compare it to y

function doubleEqual(x, y) {
  // previous checks

  // handling case 6
  if (typeof x === 'boolean') {
    return Number(x) == y
  }

  // handling case 7
  if (typeof y === 'boolean') {
    return x == Number(y)
  }
}

Abstract equality - case 8 and 9

The final two cases, 8 and 9 check if one of them is an object and the other is either string, number, or symbol, if so, the one has the type object is compared after calling the [Symbol.toPrimtive] method from.

In case 8, if x is either string, number, symbol and y is object, we compare x as it is with the returned value from calling ToPrimitive on y

In case 9, if y is either string, number, symbol and x is object, we compare y as it is with the returned value from calling ToPrimitive on x

function doubleEqual(x, y) {
  // previous checks
  // handling case 8
  if (
    (typeof x === 'string' ||
      typeof x === 'number' ||
      typeof x === 'symbol') &&
    typeof y === 'object' &&
    y !== null
  ) {
    return x === y[Symbol.toPrimitive](typeof x)
  }

  // handling case 9
  if (
    (typeof y === 'string' ||
      typeof y === 'number' ||
      typeof y === 'symbol') &&
    typeof x === 'object' &&
    x !== null
  ) {
    return x[Symbol.toPrimitive](typeof y) === y
  }
}

It may have been not obvious, but those two cases require more checks that it's stated, we had to check that none of them is the null object, because as we've discussed in earlier article that null is an object in js.

And we had to invoke the ToPrimitive operation ourselves because we wanted to pass the hint to it as the typeof x assuming that this object knows to handle these types, if that sounds new to you, check my previous article where we talked about type coercion.

So putting all together, we would end up having a huge function that looks like the following.

function doubleEqual(x, y) {
  if (typeof x === typeof y) {
    return tripleEqual(x, y)
  }

  if (
    ((typeof x === 'undefined' ||
      typeof y === 'undefined') &&
      typeof x === 'object' &&
      !x) ||
    (typeof y === 'object' && !y)
  ) {
    return true
  }

  if (typeof x === 'number' && typeof y === 'string') {
    return x == Number(y)
  }

  if (typeof x === 'string' && typeof y === 'number') {
    return Number(x) == y
  }

  if (typeof x === 'boolean') {
    return Number(x) == y
  }

  if (typeof y === 'boolean') {
    return x == Number(y)
  }

  if (
    (typeof x === 'string' ||
      typeof x === 'number' ||
      typeof x === 'symbol') &&
    typeof y === 'object' &&
    y !== null
  ) {
    return x === y[Symbol.toPrimitive](typeof x)
  }

  if (
    (typeof y === 'string' ||
      typeof y === 'number' ||
      typeof y === 'symbol') &&
    typeof x === 'object' &&
    x !== null
  ) {
    return x[Symbol.toPrimitive](typeof y) === y
  }

  return false
}

Probably it's irritating for you that we're using the equal operator itself within this algorithm, but hey, how would you do other way? PS: Lemme know if you know some other way o.o

But phew, we've made it, we've mocked the double equal operation, it's hella long one and probably has some mistakes within it, but hope fully you got the sense of it.

Double equal is all about handling types and coercing them to fit - Me if none said it before

But cheer up, this isn't goodbye yet, we still have to talk about triple equal and some JS wtfs :D

Strict equality operator

This operator is also renamed in the TC39 specs to isStrictlyEqual which is again a better name IMO, it indicates that this operation is delegated to a function or series of functions, which is actually what happens.

The same cycle repeats itself, the triple equal performs some checks against the two given values and reacts according to them.

Strict equality - case one

We've seen this case before, you may think why they're repeated themselves, well they're not, the double equal delegates the work to the triple equal in case the given inputs have the same types, but what about the case when you use the triple equal directly? this case has to be handled aswell. thus, they have this first case of checking against same types equality.

function tripleEqual(x, y) {
  if (typeof x !== typeof y) {
    return false
  }
}

Strict equality - case two

If the type of x is number then both of them are numbers logically, because if we're at the state of having this check, they must have passed the first check where the two inputs have to be of same type, so that's one check less.

function tripleEqual(x, y) {
  // previous checks

  if (typeof x === 'number') {
    return equalNumbers(x, y) // some outsourcing function
  }
}

function equalNumbers(x, y) {
  return !(x < y || x > y) // being fancy not using !== :D
}

Strict equality - case three

Probably the same case as before, but it checks against bigint type because numbers and big integers aren't the same, yeah they're numbers after all, but in terms of representations they're different.

function tripleEqual(x, y) {
  // previous checks

  if (typeof x === 'bigint') {
    return equalBigIntNumbers(x, y) // some outsourcing function
  }
}

function equalBigIntNumbers(x, y) {
  return !(x < y || x > y) // Dunno other way of checking against bigints tbh
}

Strict equality - case four

This one actually is the one we cannot have a code representation of, because it uses memory addresses and some things we can't access using native JS, but we'll have another hack representing that our memory is just an object

This case returns the value of comparing two non numeric values if they're the same or not, which denotes that the triple equal is mostly about comparing numbers, the three previous cases were against types and one was about immediate return if types mismatch.

And I find this behaviour kinda reasonable, we have the double equal to handle different types and make them suitable for each other, and we also have the double equal invoking the triple equal if the types are exact, so why not delegate numbers handling to triple equal? because later on we will find out that the double equal always yields to a triple equal operation.

But for now, let's walk through this SameValueNonNumeric operation and see how it behaves.

SameValueNonNuemric operation

This operation starts off by making an assertion that those types are exact, which makes it reasonable to invoke this operation from the triple equal operation not the double equal.

Afterwards it goes through a list of checkings about these inputs.

Same value non numeric - case two

In this step, the algorithm checks if is x is undefined, if so, it returns true, because that means that both of them are undefined based on the assertion made earlier.

function sameValueNonNumeric<T>(x: T, y: T): boolean {
  if (typeof x !== typeof y) {
    throw new Error('Type mismatch error') // Semi assertion
  }

  if (typeof x === 'undefined') {
    return true
  }
}

Same value non numeric - case three

This step is more like the previous one, but checks if they're nulls

function sameValueNonNumeric<T>(x: T, y: T): boolean {
  // previous checks

  // we have to check that its the null object using !x
  if (typeof x === 'object' && !x) {
    return true
  }
}

Same value non numeric - case four

If x is string, then the comparison is done according to their unicode representation

function sameValueNonNumeric<T>(x: T, y: T): boolean {
  // previous checks

  if (typeof x === 'string') {
    return compareUsingUnicode(x, y) // some imaginary function does the comparison
  }
}

Same value non numeric - case five

If x is boolean, a.k.a both of them are booleans, we must check that both are whether true or false

function sameValueNonNumeric<T>(x: T, y: T): boolean {
  // previous checks

  if (typeof x == 'boolean') {
    return (x && y) || (!x && !y)
    // either both are true booleans or both are false booleans
  }
}

Same value non numeric - case six and seven

Those steps check if they're of the type symbol and objects, but I'll skip the implementation because it may become more complex as we have to make memory-like hash map and something represent the memory reference/id, but hopefully you get the idea behind it, it's compared using their memory id

Phew, I'm really glad if you've made it to here, here's some motivation for you to keep going.

So, after all of this, what's next? Well, hopefully you knew what's the major difference between double equal and tripe equal, they both check types, but each one makes a different use of them, so let me put a definition of how I understand the difference.

Double equal and tripe equal operations are exact if types are met, otherwise, the double equal makes use of type coercion while triple equal doesn't.

Let's have some examples to solidify what you learnt about these differences, but before we do so, let's revisit something I mentioned, that the double equal operation makes use of triple equal eventually.

I think you've noticed that through the coding examples we've made, that whenever the types are the same, the double equal operation invokes the triple equal operation, but that's not what I meant.

Actually, the double equal operation is a recursive operation not sequential through some conditions.

It's true that we have these checks, but whenever a condition is met, we recursively invoke this doubleEqual function to yield back to the tripleEqual after coercing both types to an intermediate type which is equal in both cases according to the conditions we've seen.

So, with that in mind, let's walk through some code examples, or to put it more precisely, some JS WATs or WTFs, whichever you wanna call them.

WTF JavaScript #1

console.log([] == ![]) // true

Probably this is one of the most famous wtfs in JS, how come an array is not equal to itself, but probably you can make sense out of it, take a couple of mins thinking of it.

We're back after this little pause, hopefully you've figured it out, but if not, the answer is very simple, type coercion came in place

Sure that's the short answer, so let's have a deeper look.

For the sake of clarification, let's name these arrays posts and tweets as in they're response from some API

let posts = []
let tweets = []

if (posts == !tweets) {
  // this code will run
}

Alright, that's the same logic as before, what next?

Well let's have a deeper look at the operations in order, first the posts array is untouched, and the double equal operation is nothing new, but this negate operator ! around the array.

This operator is a type coercion operation, because you can't negate strings, or any non-boolean type, right?

So it has to cast this type first to boolean a.k.a calling Boolean(tweets) and we've discussed this before in a previous article, the ToBoolean operation is a look up operation against the falsy values, which doesn't include arrays, so the ToBoolean operation over an array even it's empty will return true and the negation will make it false

So once again, the operation is recursively invoked with the new values/types, as if we're doing now doubleEqual([], false)

So now this operation is invoked with two different types, so the first condition of invoking triple equal is delayed.

I don't know if I said or not, but it's easier for the language to compare primitives, thus it converts the non-primitive type to a primitive one, a.k.a coercing the array to a string because it's easier.

So the comparison ends up being something like the following.

let posts = []
let tweets = []

if ('' == false) {
  // this code will run
}

Once again, they are different types, so we have to coerce them to an intermediate type so we can invoke the triple equal operation.

So, which one would be suitable to coerce a string and a boolean to? YES, number

Meh, only if "" becomes NaN

So yea, they both become zeros as discussed before. And the comparison becomes something like the following.

let posts = []
let tweets = []

if (0 == 0) {
  // this code will run
}

And finally, they're both of the type number so the triple equal operation is invoked given these two inputs which returns true ofc.

WTF JavaScript #2

console.log([] != [])

Hopefully you're like ha, we've seen this one just couple of seconds ago, they'll be coerced and whatsoever.

Umm, no, this one is actually whole different story, there's no type coercion involved here, have a second look, they're both of the type array, no coercy operation is involved, the previous one has ![] which was a coercive operation.

So how this one is handled?

Easily, it invokes the tripe equal operation directly which will fail the first 2 cases of number checks and bigInt check and invoke the SameValueNonNumber operation.

We can write this check in another form that may look more friendly

console.log(!([] == []))

I think you've seen this one before, like an array is not equal to itself? wtf js

That's actually reasonable, because as the SameValueNonNumber operation indicates, these two are compared using their memory references, which absolutely different ones.

WTF JavaScript #3

let posts = []

if (posts) {
  // passes
}

if (posts == true) {
  // fails? WTF
}

if (posts == false) {
  // passes!! aight that's it with js
}

Hopefully this one is new to you, but we've discussed it at #1 wtf, but let's illustrate it.

The if statement invokes the ToBoolean operation within its condition body, I think that's already known from your day one in programming.

Due to this behaviour, anything that's not a comparison gets coerced to a boolean value, otherwise we couldn't have this code branch evaluated.

And what an empty array gets coerced to as a boolean? Yeppy, true because it's not in the falsy table.

If so, why tf when compared to true it fails!

Because this a whole different operation, this is a comparison operation, so it coerces both operands to an intermediate type, and surely it starts with the non-primitive type and calls ToPrimitive on it, and once again, what's the result of coercing an array to a primitive? Yea, an empty string if the array is empty.

So the comparison will be like the following

let posts = []

if (true) {
  // passes
}

if ('' == true) {
  // fails? WTF
}

if ('' == false) {
  // passes!! aight that's it with js
}

And once again, the two operands are of different types, which leads to another coercion operation so we can invoke the triple equal operation, and which one is easier to coerce this time?

You got it right, the empty string, which becomes zero, now the comparison is between number and boolean, so the boolean is also coerced to become a number, so the comparisons end up like the following.

if (0 == 1) {
  // fails? WTF
}

if (0 == 0) {
  // passes!! aight that's it with js
}

So yeah, sure they're reasonable now.

Note: I may not haven't mentioned it, but the language favors numeric comparisons as they're easier to compute, so it always try to coerce types to their numeric form.

WTF JavaScript #4

This one is so famous that it was made as a meme, but once again, this is where bugs come from, the divergence of thinking between you and how the language thinks. And guess what, JavaScript is always right of how she thinks.

So let's get into it and analyze what happens here, first of, 0 == "0" this one is quite easy I hope, a number compared to a string, and we've stated earlier that the language favours the numeric comparisons, so it coerces the string to a number which makes the comparison 0 == 0 which invokes the triple equal operation and returns true.

Secondly, we have 0 == [], which is again non-primitive or non-numeric compared to a number, so the ToPrimitive operation is invoked on the array which returns "" empty string, then the previous operation is repeated and it coerces the empty string to zero, then invokes the triple equal operation which returns true.

Lastly is where the confusion rises, "0" == [] returns false, hopefully you find this logical.

We start off by checking the types, string and array, so the non-primitive type gets coerced to it's primitive form, which makes the array empty string, which makes the comparison "0" == "" and voila, they're of the same type, the triple equal is invoked with two strings, which invokes the compareUsingUnicode function we've defined earlier, which checks if the strings share the same unicodes, surely they don't here, its an empty string and a zero as a string comparison, thus it returns false.

Conclusion

It was a long way to make it here from the very first article, I'm proud of you xD

So let's wrap up what we have discussed within these four articles and my thoughts about them.

Whether the language is nuts or we are for using it, I am quite sure you know how powerful JavaScript is, but it's reasonable that you use a tool and understand how it works, you should have a solid mental model of what the language has to offer, you'd be really missing a useful tool within your tool belt when you say "Coercion is bad, I will let the triple equal handle these cases for me".

I can't claim that coercion doesn't have crazy edge cases in the language, probably they're specific to JS, I don't know about you, but I come from a PHP background, and most of these cases do not exist there, but I can guarantee you, JavaScript has more to offer than PHP, they both differ internally of course, and the intention and use cases behind each language is different, but for me as a web dev, I find JS has more to offer, at least in the back-end division, but sure that's out of subject, I am not comparing languages here.

All I am trying to say that don't ever judge a feature of the language, embrace it and understand it better, that's how you make a better software engineer of yourself and the others around you.

Hope you've liked this series and and found it useful 👼

Have a nice drink and a wish you a very pleasing day, Cheerio 💜

Consider supporting/following me

JavaScript weird type system - Boxing

Ahmed Osama — Fri, 26 Nov 2021 14:52:32 +0000

Aloha, it's nice to have you again in another article, in this one we'll be talking about one concept that exists withing JS but probably mis-understood and this misunderstanding leads to inaccurate mental models.

Boxing

So what is boxing? well let me define boxing according to how I understand it.

Boxing is more like wrapping some value of type of x in a container that is type of y which has more functionalities that x can use - Some panda

Hopefully I did great job getting you confused, I think that's what academic definitions are all about after all 🥲

But let's break down this definition, let's assume that we have some value of the type x, for simplicity, let's say that x is the well known type string, so our value may be name = 'ahmed osama'

So that's the first part of my definition, that we assume we have a value of some type, moving on to the second part.

We want to wrap this value 'ahmed osama' of type string in some other container of type y to have more functionality we may need in our string type.

So what about putting our string value in an object container maybe?

And what about we choose the array object to wrap our object within?

I hope you're getting a sense of where are we going with this, but lemme help you.

I presume you have gone through the following code snippet over billions times, ever though how tf this is possible to treat strings as objects?

let name = 'Ahmed osama'

console.log(name.length) // 11
console.log(name.includes('e')) // true

Everything in JavaScript is an object

One of the most famous sayings in JS and I truly don't know who came up with this one, rumor has it that Douglas Crockford stated this.

Whomever said this quote is probably wrong, at least in the abstract sense without anymore clarifications.

But, he still has a point, probably whomever stated this quote, he was speaking in the sense of prototypes, as known in JS, most of the primitive data-types can be constructed using their object-ish constructors.

let myTrue = new Boolean(true)
let name = new String('ahmed osama')

console.log(typeof myTrue) // object
console.log(typeof name) // object

And surely that makes everything in JavaScript an object, but once again, this definition or quote has some ambiguity around it, does that mean that the letter a itself is an object of type String or the identifier name itself is the object and it contains within it some primitives?

Does that mean that JavaScript doesn't have the primitive data types within it?

And many other questions may rise due this conflict.

And sure, JavaScript nor any other programming language can work without having the primitive data types within it, how would you store your data if that happened?

All known data - as far as I've seen - yield down to become strings and numbers, I'm not talking about how they're stored in our application/memory, yes that may vary between many options: arrays, hash-tables (jsons), binary tree and many other options.

But whenever you simplify it to the extreme, what you end up with is a bunch of strings and numbers to represent some user, maybe details about him like his SSN, phone number, name, street or whatever you may accept.

And once again, I am not making this up of my own, ES specs itself stated that JavaScript must contain primitive data types and sorted them in the well known list of string, number, undefined and the other non-object ones.

So I may re-quote it in a more applicable one - atleast in my point of view -

Primitive data types in JavaScript are not objects, but can be treated as if they were ones due to boxing, which gives a feeling that everything in javascript is object-like.

I belive this definition is more accurate and doesn't leave any ambiguity behind, hopefully.

So, let's revisit my definition of boxing, it's all about wrapping some value of type x in another type y and it should behave as if it was of type y a.k.a has the functionalities of y.

That's exactly what happened when we accessed name.includes('e'), the string ahmed osama was wrapped in another type that has this method includes.

How lucky, we have two types within JavaScript that have this method in their prototype, Array and String (The capital initial means the constructor version)

const someString = new String('abc')
const someArray = new Array(15)

console.log(someString.__proto__)
console.log(someArray.__proto__)

If you run this code snippet in some browser environment (node didn't work for me it showed soem non-helpful representation), you may find something that looks like that.

Note: Click here for string prototype or here for array prototype

An array of all the possible methods with the String.prototype, so your primitive string is some how turned into it's object form so you can acess these methods.

Let's have another example of wrapping your types into another containers so you have more functionality over them.

In function programming there exists some concept called Monad which is some how close to what we're discussing.

Let's say that we want to create a container for any value and support it with some more functions, I'd go with something like the following.

// First lets define the acceptable types
type Primitive =
  | string
  | number
  | boolean
  | undefined
  | null

type JsonArray = Json[]
type JsonObject = { [k: string]: Json }
type Json = JsonObject | JsonArray | Primitive

// Next, let's define our Box

const Box = <T extends Json>(x: T) => ({
  map: <U extends Json>(f: (v: T) => U) => Box(f(x)),
  filter: (f: (v: T) => boolean) =>
    f(x) ? Box(f(x)) : Box(undefined),
  fold: (f: (v: T) => T) => f(x),
})

So what's this we are building?

Well, we're just making a function that accepts any type that's not a function, because that's what a JSON type is anyway, and returning an object that contains multiple functions/operations that operate against the given value.

And for the sake of simplicity, I just included map and filter operations within the box, surely you can provide any desired operation.

And the fold operation is just a function to extract out the value after manipulation outside of the box.

So let's use our box to manipulate some value.

let myName = Box('ahmed osama')
  .map((v) => v.toUpperCase())
  .map((v) => v.split(''))
  .map((v) => v.sort())
  .map((v) => v.join(' '))
  .map((v) => v.trim())
  .fold((x) => x)

So what are doing here?

Well first, we're creating a box around the value 'ahmed osama' so we can have more functionality.
Then we're mapping the string to the uppercase form of it, note that this map function we have is a little bit different the regular map function that's provided within the language, as it doesn't wrap the output in an array, it returns it with the same type provided.
Afterwards, we're once again mapping the returned caplitalized string to split it into its characters
We're sorting the array of characters so we have my name in sorted chars.
We're joining it back to a string separated by spaces
Them we trim the output as we have trailing spaces
Finally we fold the ouput a.k.a extracting it out of the box by applying the identity function

console.log(myName) // A A A D E H M M O S

We ended up having my name split into sorted uppercased characters.

Some naive process yeah but hopefully you get the idea behind it, we wrapped the primitive string in an object container that has mutliple functions that can operate against this string type to ahcieve something.

And that's simply Boxing :D

Now that's done with, I'll see you in the next part ^^

Have a nice drink and a wish you a very pleasing day, Cheerio 💜

Consider supporting/following me

JavaScript weird type system - Type coercion is bad

Ahmed Osama — Wed, 24 Nov 2021 12:57:04 +0000

Heyaa, welcome back, I hope you're doing well, in the previous article we've discussed basic data types and some discussions around some types, you can check it up if you don't know about that.

But now we're going to talk about the:

Type Coercion

One of the most important and underrated concepts related to types, I'd go saying if you don't understand type coercion and how it works, you won't be able to reason about your code base.

How would you make an algorithm if you're ignoring if types coerce to another type?

That's where bugs come from btw, the divergence of your mental model or intention and how JavaScript behaves and thinks, and yeh, JS never mistakes.. umm, maybe a little bit.. aight, JS messes up with types, so help her!

I don't know about you, but I find these anti-coercion people who claim that type-coercion is evil, are evil themselves.

How could you drop off some built-in feature from the language?!

And hey, that's not some avoidable feature, you're using implicit coercion and maybe you don't know, guess what, how hard you try to avoid coercion and be explicit about your types and cast according to the situation yada yada yada. You still coerce!

JavaScript uses coercion internaly whether you like or not, so why not we embrace this feature instead of avoiding it?

You'd make a better developer of yourself if you're using every possible feature of the language the right way, instead of using some features and ignore some others.

If you're typing more reasonable code to JavaScript you'll have narrowed down the divergence between your mental model and JS intention which results in better code base.

So what's type coercion all about?

Type coerion is changing type from X to Y - Me

Some fucked up definition I know, but trust me that's all it takes to reason about type coercion, let's walk through some code examples.

console.log(Number('abc')) // NaN
console.log(Number({ x: 1, y: 2 })) // NaN
console.log(Number([1, 2, 3, 4])) // NaN
console.log(Number('5')) // 5
console.log(Number(true)) // 1

Sounds familiar code snippet? yeah that's the earlier one we used for exploring NaNs, that's type coercion, we're coercing the values from being string, objects, arrays to numbers

So my definition isn't that bad after all ^-^

But hey, that's not it, there's like hella lot more to coercion, so let's dig in.

valueOf

Ever tried numerifying your objects a.k.a calling console.log(Number({}))?

If you haven't, it will return NaN which is reasonable, we can't represent objects as numbers. but what if we desperately need to?

That's where valueOf comes into play, the valueOf operation can be used to override the internal behaviour of coercing objects to numbers, consider the following example.

Let's say you are hitting the github API to fetch some user repos and want to calculate total stars the user has.

let user = {
  username: 'ahmedosama-st',
  repos: [
    {
      id: 1,
      title: 'php-mvc-project',
      stars: 10,
    },
    {
      id: 2,
      title: 'filemarket',
      stars: 5,
    },
  ],
}

let userStars = Number(user) // returns NaN for sure.

so how can we encounter this situation to make the numeric representation of user object to be the sum of all it's repos' stars?

you can specifiy the desired behavior in the valueOf function in any object and it will be automatically invoked if you're trying to numerify the object.

let user = {
  username: 'ahmedosama-st',
  repos: [
    {
      id: 1,
      title: 'php-mvc-project',
      stars: 10,
    },
    {
      id: 2,
      title: 'filemarket',
      stars: 5,
    },
  ],

  valueOf() {
    return this.repos
      .map((repo) => repo.stars)
      .reduce((x, y) => x + y)
  },
}

console.log(Number(user)) // 15

Yaay, it works. but wtf are you doing xD?

Like seriously, why on earth would I want to represent some algorithm as the numerification of some object, imagine that you're a using some package that does so, how would you react to coercing your object returns you some intended behavior?

I'd strongly argue you should never do so, maybe that's lack of experience from my end that I haven't encountered a situation where this is useful, but until that happens, that's no use code.

Furthermore, speaking in terms of clean code and refactorability, it's highly likely you'll re-use such behavior which makes it more reasonable to extract it as an internal method that has a semantic name to deduce from it what it does.

let user = {
  username: 'ahmedosama-st',
  repos: [
    {
      id: 1,
      title: 'php-mvc-project',
      stars: 10,
    },
    {
      id: 2,
      title: 'filemarket',
      stars: 5,
    },
  ],

  totalRepoStars() {
    return this.repos
      .map((repo) => repo.stars)
      .reduce((x, y) => x + y)
  },
}

console.log(Number(user)) // NaN as it should be
console.log(user.totalRepoStars) // 15

It just took you one line of change, just change the method name and bam, you've achieved readability, clean code, yada yada yada.

toBoolean

This one is heavily used internaly, you might not have used it yourself, but the language makes a huge usage out of it, imagine everytime you're using an if statement or the double equal operator, the toBoolean operation is high likely to be called.

This operation is more of a look up operation than manipulating types, I guess you already know about the falsy table in JS.

Falsy values
zeros / 0, -0
empty string / "", ''
null
NaN
undefined
false

Any other value is considered a truthy value and passes in if statements.

So knowing that, what would you think will be the output of this code?

Boolean(new Boolean(false)) // ??

It would be true, because using the function Boolean means coerce the given input to a boolean type.

But using it as a constructor function, means constructing an ew object, which is of type object, which doesn't exist in the falsy table. thus it's true

toString

I think this is the most famous coercing operation, we use it daily debugging our objects and inspecting them, but the default behaviour isn't quite helpful as it produces [Object object] like wtf? I know it's an object yo.

So you can override this operation as well and specifiy your own implementation

let user = {
  username: 'ahmedosama_st',
  website: 'https://ahmedosama-st.github.io/codefolio/',
  skills: [
    {
      skill_name: 'php',
      years_of_experience: 5,
      favourite_frameworks: ['laravel', 'symfony', 'lumen'],
    },
    {
      skill_name: 'javascript',
      years_of_experience: 2,
      favourite_frameworks: [
        'react.js',
        'nest.js',
        'vue.js',
      ],
    },
  ],

  toString() {
    // return JSON.stringify(this, null, 2)
    // but I'd use util as it has coloring
    return require('util').inspect(this, false, null, true)
  },
}

Both implementations would work if you're having some nested object like the one I made as they're recursive operations.

And tbh, I think this override is a useful behaviour, atleast it makes sense and it's reasonable, you're having a deep inspection of your object which is logical.

ToPrimitive

It's some sort of internal operation that runs whenever you're trying to coerce some non-primitive type into a primtive (as the name suggests..)

And this operation can be though of the combination of the two previous operations, valueOf and toString

Let's see what ES specs has to say about this

"Aight, I'm not gonna read through that", don't worry I read it for you.

Let's see, the ToPrimitive operation is meant to coerce objects to other types, you can control how it behaves to even coerce to another non-primitive type, but c'mon, what are you thinking?

As you try to coerce some object to another type, to ToPrimtive operation is invoked, and the desired type is passed as an argument called hint, and the coercee -if that's a word- is passed as input

And the function goes through some steps as illustrated, 2 steps, If the coercee a.k.a input is an object, them some further steps will be done, otherwise return it untouched.

So you can say that it only works on coercing objects from a type to another, which is reasonable, what is the intent of coercing an object to an object?

So, what happens if I want to coerce my object to string or a number?

I think you can take a guess, if the passed hint is number the valueOf operation will be triggered first if existed, otherwise it'll return NaN, and by similarity, if you're coercing it into a string, if a custom implementation of toString is provided, it'll be invoked, otherwise, it'll fall back to the default behaviour and return [Object object]

I.E. you can replace the two previous operations with tis one and conditionally return desired output let's see this through code

let user = {
  username: 'ahmedosama-st',
  posts: [
    {
      id: 1,
      title: 'Exploring the V8 engine',
      url: 'example.com',
    },
  ],

  [Symbol.toPrimitive](hint) {
    if (hint == 'string') {
      return require('util').inspect(
        this,
        false,
        null,
        true,
      )
    } else if (hint == 'number') {
      return this.posts.length
    }
  },
}

console.log(String(user)) // {username: 'ahmedosama', posts: [...], ...}
console.log(Number(user)) // 1

Note: The default behaviour of ToPrimitive is to fallback to set hint to number if no hint is passed

Also note: If you try to do Boolean(user) it will not behave as you expect, it will fall back to the truthy/falsy table to check whether if this value if in the falsy table or not.

So what if you wish to alter this behavior? maybe for some reason you want to coerce some object to an array, Idk why would you do so, but let's see how it's possible.

The ToPrimitive is defined by a Symbol as a function, or a special function if you will, so you can invoke it this way and pass manual type as a hint and handle it within the function's body, but once more, please don't do so, it's complete nonsense.

let user = {
  username: 'ahmedosama-st',
  posts: [
    {
      id: 1,
      title: 'Exploring the V8 engine',
      url: 'example.com',
    },
  ],

  [Symbol.toPrimitive](hint) {
    if (hint == 'array') {
      return this.posts
    }
  },
}
// Note, that you have to call it yourself.
console.log(user[Symbol.toPrimitive]('array'))

Yes it will behave as you wish, and return the posts array, but once again, wtf are you thinking?

I think these coercions are better used to flex around or maybe in the context of an interview where you'd like to show that you deeply know types.

Meh, enough with these internal operations, let's move onto another topic.

Some corner cases of coercion

Sometimes coercing types can become a little bit messed up in JS, let's walk through this and reason about it.

Empty strings are zeros

Number('') // 0

This one is the root of all evil, I really can't get it why did JavaScript implement the coercion of an empty string to the zero number.

I'd like to think that the empty string is a representation of no characters, what on earth that has to do with zero?

Zero doesn't represent the absence of a numeric value, it's a real number and actually, it's one of the most important numbers in math.

So why to represent the absence of chars with a real numeric important value like zero when JavaScript actually has a solid existing type that's dedicated for non-numeric representations a.k.a NaN, like c'mon JS why are you doing this to us...

Even non-alpha a.k.a white spaces strings are represented as 0

Number('   \t\t\n') // 0

Because JavaScript gets in and says: "Ha got it, you're trying to turn a string into a number, let me trim it first :D", Yeah, thanks js..

But meh, what I'm arguing, I already stated it, if we're doing JS, we're gotta do it her way.

I think you're like rn, "Ahmed, you're a drama queen".

Well, that's a topic for another time, but trust me this idea of coercing empty strings causes all the non-reasonable behaviors of JS, and we'll get to them shortly.

Let's move onto the next weird coercion.

Null is also zero

Number(null) // 0

Yeey, empty strings aren't the only values that yield to zeros when coereced. Whispers: HATE YOU JS!

Well, once more, it should've been NaN, like come on! the ES spec itself stated that null represents the empty object or the absence of an object, zero isn't the right thing for that.

If you think this not a big deal, check out this code snippet from Stack over flow

And let's see the following example.

Number(null) // returns 0, sooo...
0 == null // sorry, false..
null == '' // again, false
null >= 0 // true FFS!!!
null >= '' // true, and here is where you quit JS
null <= '' // true, and now you're quite certain JS is fucked up

Hopefully you see how much this is messed up, and don't worry we'll walk through all these cases and why tf this behaviour occurs in the Equality section

Undefined is NaN

Number(undefined) // NaN

This one is the most hurting one, like really? that's when you realized you have a dedicated type to represent non-numeric representation, sigh, give me a break JS.

This is the most accurate one I'd say, becuase undefined is intended to represent absence of a value, and NaN as we discussed earlier, is the representation of non-valid numbers a.k.a absence of a numeric values.

Empty arrays are zeros

Number([]) // 0

I'll not whine or nag anymore I promise, this one is reasonable -According to JavaScript ofc-

What happens is this conversion is performed on two steps, because -as far as I know- JavaScript cannot convert non-primitives to numbers directly, it has to simplify it to the first possible type.

And unfortunately, the first primtive type that arrays yield to is string.. so yeah the loop repeats itself, and this operation goes as the following.

/* Intended */
Number([])

/* Goes through */

Number(String([]))
// or for simplification
let x = String([]) // ""
Number(x) // 0

So yeah, that's why I told ya, empty string coercions is the root of all evil.

Guess what, it even takes it further more to some more crazy stuff.

Number([null]) // 0
Number([undefined]) // 0

Amazing JS, why did you do that again? oh yeah because you decided that empty string is 0

So let's reason about what happens

Number([null])

We have agreed that this can't be done directly, but rather delegated to the coercion of strings.

Number(String([null]))

So what does String([null]) returns? Yup, the empty string.

Because JS decided that the stringification of an array is just removing the square brackets and non-occupied values, I.E, String([1,2,3]) returns "1,2,3" and if it happened that an array has either null or undefined it will be represented by empty spot like that String([1, 2, null, 4]) becomes "1,2,,4" the position of null is empty and that's completely nonsense, and what's more nonsensical, that String([null]) becomes empty string, like not even a comma floating around so it becomes NaN.

Conclusion

Type coercion exists whether you like it or not, so my hunch is, understand it, make use of what the language has to offer rather than dropping off some parts.

It's nonsensical to say that I will allow some type coercion of the langauge and ignore some other, it's whether you accept the whole feature or don't use it at all, and in this case, you can never ignore coercion, the language uses it internaly.

What I would recommend is, make sure that you avoid the corner cases of coercion, make sure that you're accepting just the right types for your functions.

If you're working on some algorithm, some sorting algorithm that deals with users and sorts them based on some criteria, if you want to make this algorithm flexible in some sorts, I'd say I may accept either strings for usernames maybe or numbers for reputation or total stars if they're github users , and that would be it, I'll make type guards for any other type to reject it.

function sort(a, b) {
  if (!isAcceptableType(a) || !isAcceptableType(b)) return

  // Perform my algorithm if they're acceptable.

  function isAcceptableType(value) {
    return ['string', 'number'].includes(typeof value)
  }
}

Yes I've reduced the hassle of dealing with objects, booleans, arrays and also allowed some sort of type coercion, sure I'd go further more handling some of the weird edge cases like coercing the empty string to zero and other cases we've looked at, but I will end up with some flexible sorting algorithm

I think this sums it up for this article, sure I haven't covered all corner cases or coercion or all the processes of coercion, because it would be more like 2 hours of reading and too much effort to do.

So I'll leave you some resources for further reading.

Further inspection

Coercion table

Cheerio, have a nice drink and a wish you a very pleasing day 💜

Consider supporting/following me

The weird JavaScript type system - typeof and NaNs

Ahmed Osama — Wed, 24 Nov 2021 10:49:49 +0000

Heya, nice to see you again in another article, today's topic is kind off functional programming, I thought it my be nice to get back the basics and talk about types which is one of my favourite topics.

So why not have a series that's dedicated to the typesystem that JS has?

In this article I'll to go all beasty about types and why you should really care about types, so hold tight and let's go.

"Stop using double equal, tripe equal for the way", you often see this recommendation in some courses, blogs, and even books that favors the tripe equal === over the double equal == as they claim it's better in terms of handling corner cases. HELL NO

I won't argue that back in time I believed such claim and even spread it in some of my courses, articles. But meh, we all do silly things.

So, let's get right into our topic and understand why I am so that irritated of this claim

What types does JS have?

Surely you know what types the language you use supports, but bare with me and let's revisit them swiftly.

Primitives
- String
- Number
- Undefined, NULL
- Symbol
- Boolean
Object
- object (The object notation or an instance of a class maybe)
- Array
- Function

All the primitive types are treated by javascript as non-reference values a.k.a they get stored on the stack not the heap (We'll have another article about that I promise).

And all the descendendants of the Object type are treated as Referenceable values, as they get stored on the heap and their reference is stored on the stack

The typeof Operator

This operator is kinda special as it's the only operator in javascript that can access non-existing variables in any scope, let's see the following example.

Undeclared

console.log(typeof undeclared) // undefined

Apparently, the variable undeclared doesn't exist in any scope, yet the typeof can access it, but what distrubs me that it returns undefined :/

Well, it might seem reasonable, but IMHO, I like to think of undefined as a representation of no value, more like the absence of a value, and I might assume that you too think of it like that, more like a placeholder to an upcoming value, consider the following example.

class User {
  protected db: Database

  constructor(db: Database) {
    this.db = db
  }
}

You're expecting the variable db to be instance of some Database entity, maybe you're injecting it to your User model to handle incoming requests related to database persistency.

Apart from that, what is the value of db before you pass it any instance? Yup, it's undefined, you haven't setted a value for it yet, so the absence of a value is represented by the keyword undefined, hopefully that makes sense.

But if so, what's the problem with returning undefined using typeof operator for non-existing variable?

Well, I agree with Kyle Simpson that this is some sort of confusion, using the same data type for two separate concepts is not accurate, JavaScript could've introduced new type called undeclared to indicate that some variable is not defined in any accessible scope.

Further, neither me nor Kyle thought of this mental models by ourselves nor did anyone has this mental model, actually the EcmaScript guidelines says so.

But meh, adding something like this may cause a lot of bugs to existing code basis, you never know if someone uses such code.

Null is an object

let v = null

console.log(typeof v) // object

One of the weirdest parts of JavasScript, that it treats the null as if it's an object.

Well, I think there are two mental models that justify this behavior.

Null is a representation of an empty object
Null is just equal to undefined and that's a JS bug

Well let's walk through each behaviour and I'll let you decide which one makes more sense.

Null is an empty object

Consider the following piece of code.

let nullObject = Object.create(null)

console.log(nullObject)

The output of this code would be something like [Object: null prototype] {}, thus there are some opinions or thoughts that the null type in JS is treated as object because it can be used as a prototype to other objects a.k.a if you want to create functionless -if you will- object which has no prototypes, therefore, it has any built-in support from JS object functionalities.

let nullObject = Object.create(null)
let anotherObject = {}

console.log(anotherObject.toString()) // [Object object]
console.log(nullObject.toString()) // Throws an error

And once again, I am not making this up, that's what the EcmaScript specs says about the null type

Null is undefined

I think this way of thinking is based on the idea that console.log(null == undefined) returns true or maybe you're like me, shifting from another language (PHP in my case) to JavaScript, either way, I think those both mental models are incorrect in some sense.

The first one totally ignores the fact that console.log(null === undefined) returns false which makes them completely different, and the second one judges JavaScript by other languages'rules, which is more worse.

If you're doing JavaScript, do it in JavaScript way - Panda's Law #2

Yet, there are some corner cases that I'd like to treat null and undefined as equal types: If it makes sense!!

If I can write more concise code using the fact that they're equal in abstract (We'll explain this later in the Equality section of this series), sure I'll do so.

Arrays are objects

This one is quite easy I'd say, but let's walk through it.

let ages = [20, 21, 26, 42]

console.log(typeof ages) // "object"

This one is completely reasonable, as I mentioned earlier, the V8 engine treats arrays and objects alike in some ways to reduce the duplications in memory allocation (I promise there will an article for that..)

Therefore, if you want to make sure that some variable is an array, you have to use the Array constructor

let ages = [20, 21, 26, 42]

console.log(Array.isArray(ages)) // true

And I think the rest of the types are quite reasonable about, like typeof function(){} returns "function" and so on.

The special type NaN

The #1 misunderstood type in JS, I think if IEEE was paid 1 dollar for everytime the NaN thought to be not a number they would've been #1 in Nasdaq..

Yeh the NaN is made to be though of as Not a number but meh, not the real meaning of not being a number!!

console.log(typeof NaN) // number

Like c'mon! the typeof operator says it's a number :"

I'd blame IEEE for not calling it NavN which stands for Not a valid number or NarN which stands for Not a representable number because that's what NaNs are.

consider the following examples.

console.log(Number('abc')) // NaN
console.log(Number({ x: 1, y: 2 })) // NaN
console.log(Number([1, 2, 3, 4])) // NaN
console.log(Number('5')) // 5
console.log(Number(true)) // 1

So NaNs actually are numbers, but special number that cannot be represented in a numeric form, and I'll refer back to why we're having this argument.

Now that's done with, I'll see you in the next part ^^

Have a nice drink and a wish you a very pleasing day, Cheerio 💜

Consider supporting/following me

The ultimate explanation of closures

Ahmed Osama — Sat, 20 Nov 2021 10:19:55 +0000

Soo, we're back again with some functional-ish concept. Closures?

I don't know if I haven't said it enough yet, but most of the functional programming concepts are inspired from mathematical concepts, probably that's why they're hard to grasp :"

So what's about this word "closure" and what makes this very concept so special that I talk about?

Well let's first inspect the mathematical concept itself and maybe we can make a projection on typescript/javascript.

In mathematics, a set is closed under an operation if performing that operation on members of the set always produces a member of that set.

Yeah sure.. set? member? totally understandable yeh.

Aight aight, mathematical definitions are always yucky, so let's simplify this one which yields to a common sense.

Let's say that we have the following operation x + y = z and the inputs x and y are of the type integer, take 2 seconds to infer the type of the variable z, surely integer!!

And that is what a closure is in simple words, the set of integers is closed over the operation addition, in other words, any addition between integers will always yield to an integer which within the same set a.k.a Closed Over (Closure)

Alright, what the hell that has to do with typescript?

Well, let's try make a projection from this concept to typescript.

If a closure occurs when an operation is done on a set and returns the same member of this set, which type in typescript/javascript or any other language that can return a type?

Exactly, Functions, they're the only type in most programming languages that can have the return keyword, thus can return a type even if itself.

And surely due to the nature of javascript that functions are first class citizens a function can return another function which makes it a higher order function

that's why Kyle Simpson in his amazing book You don't know JS that closures are only related to functions. I hope that makes sense now.

How can we define a closure in programming?

In order to define closures, we need to have prior knowledge to the lexical scope that exists within javascript environment

Lexical Scope

Lexical scope is when a group of nested functions have access to their defined variables and the variables that are defined in their parent scope. - Ahmed Osama

I hope that this definition is descriptive enough, but if not, let's inspect it through some code examples.

let x = 5
function firstLayer(): Function {
  console.log(x)

  let y = 3

  return function secondLayer(): void {
    console.log(y)
  }
}

firstLayer()() // logs 5 then 3 to the console

So, where can we inspect the existence of lexical scope?

Well, let's revisit the definition, ... group of nested functions... can be represented as the portion of code where we can return mutliple functions from our firstLayer function

... have access to their defined variables ..., surely all functions can access the functions that are defined in their scope, ... and the variables that are defined in their parent scope that's where the idea of lexical scope exists.

That functions can be thought of as layers or enclosed boxes around some data which are their variables allocated in their local memory. I.E. Execution Context which may be a topic for another article.

Hopefully that ties it down about what is lexical scope.

now let's get back to our main topic.

What is a closure?

Closure is when a function "remembers" its lexical scope even when the function is executed outside that lexical scope. - Kyle Simpson

So what did kyle mean by this definition? Let's inspect via some code snippets.

let x = 5
function firstLayer(): Function {
  console.log(x)

  let y = 3

  return function secondLayer(): void {
    console.log(y)
  }
}

firstLayer()() // logs 5 then 3 to the console

Umm, yeah it's the same code as before, that's because a closure is nothing more than defining some variables in a function and returning a function from this outer function.

These variables are lexically accessible as we discussed earlier. If so, what makes a closure different?

The difference between closure is within the definition "remembers", umm what does mean?

Well, what makes a closure a closure, the ability to re-use these variables defined in firstLayer lexical scope when executed in another lexical scope which is the global scope.

If we inspect the global scope, we wouldn't find any variables called y, but the function firstLayer has one within it's local memory, and it's auto attached to the function secondLayer (closure).

Let's walk through this with some sketching.

so what do we have here?

Well, in global memory we have the reference firstLayer pointing to some object (function) somewhere in the memory heap (We may have another article discussing this too)

and somewhere in our code we executed this function doing firstLayer(), which triggers the function and a variable called y gets stored to the local memory that's allocated by the function.

And the return keyword terminates the execution of the function and returning a function called secondLayer (Name emitted in drawing due to space) which uses the variable y

So there might be some confusion, it's known that when a program terminates, all it's allocated memory gets freed.

And our function here is a mini-program, so the allocated memory by it a.k.a the variable y shall be released and deleted from the memory.

How comes that our secondLayer function makes use of it?

The answer is closure

That's what Kyle meant by ...when a function "remembers"...

But, how is this possible? what happens under the hood? Let's see.

Apparently, when the function secondLayer is getting returned from the function firstLayer the compiler makes sure that it has all the variables it may need including the variables that may have been used lexically a.k.a y and attaches them with the function secondLayer under some special property called [[Scopes]] which includes all accessible variables by some function.

let's see some coding example.

const counter = (initial: number = 0) => ({
  decrease: (step: number = 1) => (initial -= step),
  increase: (step: number = 1) => (initial += step),
})

let x = counter()

console.log(x.increase(5)) // 5
console.log(x.increase()) // 6

So you can guess how the compiler though of this code snippet, when the function returned that object, its properties were functions that make use of our local variable initial so, it gets attached aswell to the closure property that exists on the [[scopes]] object.

I hope that wraps it up for what a closure is, now let's get to some use cases.

But I have to say it beforehand, closures are one of the most revolutionary concepts that ever existed in programming. Hope I get you convinced about that too.

Closure use cases

Partial Applications
Currying
Encapsulation
Trampolines
Stateful functions
Mocking classes behavior
Memoization
Shaping functions
Module Pattern
Generator functions
Async/Await keyword (yea..)

Phew, exploring how powerful closures are can become overwhelming, imagine that this very simple concept can yield out to all of these great implementations.

Like let's be honest, some of these concepts shape the functional programming paradigm. Guess why, because closures are one of the core pillars of functional programming.

And probably the wierdest one of them all that async/await keywords that were introduced in es2017 (I think) are some application of closures?!

Well, yeah in some sense, surely that's a topic for another article, actually most of these headlines are more like upcoming topics, one of them is already covered in another article you can check it from here Optimizing recursive functions, hopefully I can cover up the rest of these use cases soon.

For now, have a good coffee or some drink and have a very good day ❤️

Appendices and some definitions

First class citizens

First class citizen is when you can pass a value of type x as a parameter to some function y, or assign it to a variable or return it from a function. In another words, if you can treat a function as if it's a string value it's a first class citizen

Higher order functions

Higher order functions are functions that whether accept functions as their inputs or can return functions as their output.

Consider supporting/following me

Optimizing recursive functions 🚀🚀

Ahmed Osama — Sat, 22 May 2021 02:19:14 +0000

If you're not using recursion up until now you're really missing a lot of features and I may assume you haven't come across data structures yet.

I'll assume in this article you already know what a recursive function is or rather what is the concept so-called recursion, but in case you don't know, briefly a recursive function is a function that calls itself from within its inner scope.



function inception() {
  return inception()
}

inception()

So with that done with, most of us encountered the common error known as stack overflow or range error depending on which JS runtime you're using.

In addition to that recursive function exhaust our resources like hell, in terms of memory and time consumption.

So how can we surpass those two problems where we hit the walls of callstack and memory?

Well, let me introduce you to two methods that will make your recursive functions a lot faster 🏃 on the condition that you implement them correctly.

Tail call optimizations (TCO)

Tail call optimizations, Tail recursion, or Proper tail call are just interchangeable terms for the same concept, but before going through it, I think it's more convenient that we discover how our recursive functions are executed first, and why do they behave viciously to memory?

Consider the following operation as a recursive example.



function factorial(number) {
  if (number <= 1) return 1

  return number * factorial(number - 1)
}

Surely you've come across this silly example, but let us demonstrate it deeply to understand why this solution is expensive in terms of memory and time complexity.

Well, let's walk through the execution of our function giving it the input number as the value 5.

The function will have its own execution context where number is 5, afterwards, this execution context will be added on top of the callstack as a stack frame, let's ease it a bit and call this very stack frame as frame 5 (Yeah I know, such a creative name 🥱), so this frame will go through the checking if the number is less than or equal to 1 which yields to false.

Therefore, this frame executes the statement of returning number * factorial(number - 1) which is equivalent to 5 * factorial(4), and the previous operation is repeated with another frame named frame 4 and the same process is being repeated till it reaches the case where number is decreased to equal 1.

At this stage what do we have on our callstack?

The callstack in this case holds within it 5 stack frames where each frame holds the value of number that was passed to it, and waiting for the next frame to finish its execution to return the expected output of calling factorial (number - 1), so it could compute the value of number * factorial(number - 1)

Well, after the number is decreased to 1, what happens now?

In this case, the callstack has 5 stack frames on it each one holds is waiting for the next frame to return the value of factorial(number - 1) to compute its own held value of number * factorial(number - 1), and that's where the problem lies, that every stack frame holds its data and we end up having this.



function factorialTCO(number, accum = 1) {
  if (number <= 1) return accum

  return factorial(number - 1, number * accum)
}

Note: Applying TCO can also be done via defining an inner function (usually named go()) and applying the recursion to it, so you expose the same API to your client code.



function factorialTCO(number) {
  function go(number, accum = 1) {
    if (number <= 1) return accum

    return go(number - 1, accum * number)
  }

  return go(number)
}

By using tail call optimizations (TCO) we are making every stack frame pass its computed value of number * factorial(number - 1) to the next stack frame or function call whichever you would like to call it.

Therefore, each stack frame's previous no longer needs to hold any data with it as the computation is passed forward, and thus the garbage collector can freely collect these data held within the stack frames and clear them, now we have less usage 😄

Note that using TCO assumes that you return only pure recursive call, and by that I mean you must only and only return the recursive function call We will revisit this example once again using another operation that's commonly used flatten.

Any operation that is performed on the recursive function call makes the compiler of JavaScript hold what each stack frame has in terms of data or function variables, and you cannot have the performance boost given by TCOs.

In the previous example of using the regular factorial function we were operating number * factorial(number - 1) it was implying to the compiler that it must hold the data as each function call is waiting for the next function call to finish its execution, therefore, TCO cannot be applied.

Hmm but our code is still exposed to stack overflow error

Well, tail-call optimizations aren't responsible for that, but that's where Trampolines come into action.

Before explaining trampolines I want to consider another example that is consuming much more memory and stack frames and how tail-call optimizations can fix it.



function fibonacci(index) {
  if (index === 0) return 0
  if (index === 1) return 1

  return fibonacci(index - 1) + fibonacci(index - 2)
}

This problem is widely known, but what I am referring to here is the execution of it is extremely heavy as it's two stages recursion or better known as Binary Recursion where each function call invokes another two function calls.

This is overkilling the memory, imagine that our poor factorial function was exhausting our memory, and it was only recursing once, now we have a function that is recursing twice or binary.

Your stack trace would end up something like that given index is 5.

That's really where TCO can become very handy, we already stated the fact that TCOs allow your garbage collector to remove those unused data in each stack frame and passing it to the next function call, which is extremely powerful in such case, you can define any recursive function as in TCO position and take advantage of that.



function fibonacciTCO(index) {
  // firstFibonacci and secondFibonacci are usually named a and b.
  function go(
    index,
    firstFibonacci = 0,
    secondFibonacci = 1,
  ) {
    if (index === 0) return firstFibonacci
    if (index === 1) return secondFibonacci

    return go(
      index - 1,
      secondFibonacci,
      firstFibonacci + secondFibonacci,
    )
  }

  return go(index)
}

Debugging how this code is run is some sort of hassle and beyond the scope of this article, maybe another time.

But the key point here is that now this function is executing a lot faster than ever.

Umm, yeah that's great, but I cannot execute it on huge inputs that are past the limit of my stack frames, what to do now ☹️?

Meet recursive functions best friend, trampolines.

Trampolines

As shown in the GIF, trampolines for recursive functions is literally making your function calls bounce between two functions, it might sound weird and unreasonable, but trust me, that's how you'll limit your function calls between 6-7 stack frames, lets figure out how.

Now that you have made your recursive function in a tail call position, what's left that you trampolize it, by which I mean to make it bounce-able between your trampoline utility function and your lovely recursive function factorial, fibonacci, flatten ...etc.

Well, how can I achieve that? That's super easy, let's define the trampoline function and explore how it works.



function trampoline(fn) {
  return function (...args) {
    let result = fn(...args)

    while (typeof result == 'function') {
      result = result()
    }

    return result
  }
}

If you're not familiar with this style of coding, well that's derived from the functional programming coding paradigm (I have a whole course of 14+ hours on that topic 😉).

What are we defining here? We are defining a function that accepts your function that should be made bounce-able, and returning an optimized function, if you will, that is already trampolized or ready to be bounced, and that function is awaiting the arguments that should be passed to your original recursive function aka factorial, fibonacci.

Afterwards, we are looping as long as the return type of calling your function factorial, fibonacci given the inputs as ...args is a function, if so, we are invoking the next function call which means that our recursive function hasn't finished its job yet, otherwise we're done here and just returned the value that's returned from your recursive function which is stored in result.

This approach requires you to alter your recursive functions to return a closure i.e. wrapping your returned recursive call in a function to be passed to trampoline.



function factorial(number) {
  function go(number, accum = 1) {
    if (number <= 1) return accum

    return go(number - 1, accum * number)
  }

  return function () {
    return go(number)
  }
}

function fibonacci(index) {
  function go(index, a = 0, b = 1) {
    if (index == 0) return a
    if (index == 1) return b

    return go(index - 1, b, a + b)
  }

  return function () {
    return go(index)
  }
}

let trampFactorial = trampoline(factorial) // pass a reference only to the function
let trampFibonacci = trampoline(fibonacci)

Notice that we are still defining our functions in tail call position to get the advantage of the garbage collector releasing the memory allocated for each stack frame,

But, we aren't implicitly returning go(...args) but rather returning the recursive function call wrapped within an anonymous function that will be checked within trampoline if it matches the condition of looping.

Thus, your functions are heavily optimized in terms of memory, time and stack limit, you can run them with inputs up to 1e7 which is 10 million (If my math is right) and even more is possible.

Alrighty aight, that's hella great, but what about complex operations which are commonly required and used?

Let's see the flat operation which is considered the worst of them all (at least for me).

You can define a regular flat method as following:



function flat(array, depth = Infinity) {
  let result = []

  array.forEach(function (item) {
    if (!Array.isArray(item)) {
      result.push(item)
    } else if (depth === 1) {
      result = result.concat(item)
    } else {
      result = result.concat(flat(item, depth - 1))
    }
  })

  return result
}

If you're like me, someone who prefers a more functional style



function flatten(array, depth = Infinity) {
  return array.reduce(function (list, item) {
    return list.concat(
      depth > 0
        ? depth > 1 && Array.isArray(item)
          ? flatten(item, depth - 1)
          : item
        : [item],
    )
  }, [])
}

Regardless this solution is fucked up in terms of code readability, it's also not optimizable to be in tail call position, notice that we're awaiting each function call to return its value to be concatenated with list.concat operation, therefore, each stack frame holds within it its value ☹️ (Stick with the first solution)

How can we optimize this function using our two new techniques?

Well first, let's re-define it in tail call position, so we free up some memory.



function flat(array, depth = Infinity) {
  let result = []

  array.forEach(function (item) {
    if (!Array.isArray(item)) {
      result.push(item)
    } else if (depth === 1) {
      result = result.concat(item)
    } else {
      result = flat(item, depth - 1) // Yeeey tail call position, just get rid of operation
      // of result.concat so each stack frame can easily forget its held data.
    }
  })

  return result
}

Hmm, I hope it's quite obvious now what's the next step and how to achieve it.

Yup, trampolize that bloody function!! 💁‍♀️



// {... same code as before}
// just change:
result = function () {
  return flat(item, depth - 1)
}

Lastly, just define any variable to hold the returned function from calling trampoline on our flat function



let flatten = trampoline(flat)

Hooray, we're done here, our function is now ready to flat up to 30 million items with 3-4 seconds, CAN YOU IMAGINE!

Earlier, we could only flatten 10-20k items in more than 10-15 seconds, now 10-30 million is less than 5 seconds? I don't know, but that sounded insane for me the first time I implemented this method, like Tsk, Imma apply in Google dude, I'm a genius.

Breaking news: this optimized function behaves differently from the default behaviour of any flat function you'd ever see whether in JavaScript, Laravel or anywhere, Let's see why.

The default .flat JavaScript function that was introduced in ES2019 (I think) and the implementation of the Laravel framework, both maintain the data even if they are duplicates.

Consider the following examples.



let result = Array(1e5)
  .fill([[2]])
  .flat(2)



$result = Arr::flatten(
    array_fill(0, 1e5, [[2]])
);

In both scenarios whether using Laravel or native JavaScript flatten functions, the returned array from flattening those 100k elements of the [[2]] array is 100k element of the number 2 (Sharingan achieved).

But using our function:



let result = flatten(Array(1e5).fill([[2]]))

Our execution will eliminate all those duplicates, that's no coincidence, remember that we are not concatenating every value, we have eliminated list.concat, result = result.concat to achieve tail call position.

Therefore, we cannot maintain those values.

But don't frown, it's not a bug, it's a feature, right 😄?

Why don't we call our cutie function flatUnique (Modern problems require modern solutions)?

Now our function has a semantic name to what it's really doing.

Still, frowned? Well, yeah you have to, if you're a Laraveler like me, the flatten function is used almost everywhere in the core of the framework which is not allowing us to use that custom implementation, their test cases will blow up like bitch.

Well luckily, we can use the iterative solution which is a lot faster than the recursive solution, in this case, guess what, JavaScript default implementation is iterative, not recursive, and if you're a functional programmer like me, Ramda.js also implements the flatten function in an iterative manner.

So we can have both functions performing nicely, an iterative one for regular flattening and maintaining all duplicate values, and another recursive one for flattening unique items.

Conclusion

Recursion is really a powerful concept, but it must be implemented right to enjoy all of these great features, Therefore, I'd like to state my first law:

“If you don't know how to use recursion, don't use recursion”

Panda's law #1

Although that's not everything about recursion, there's yet more to it, but I believe these are the core concepts you should be aware of.

And, my friend, I really encourage you to implement your algorithms more recursively now that you understand how to gain the utmost power of recursion, but a word of truth, some operations are better performed using iterations, like that flatten that JavaScript and Ramda.js implement, the iterative solution is a lot faster than the recursive solution in case we want to maintain the same data.

Recursion is one of those concepts that are highly related to data-structures as well, and some common known sorting, searching algorithms, Yeah I know these operations can be implemented iteratively, well, anything that's iterable is recurisveable (If that is even a valid word) and vice-versa, but some problems are solved easily using recursion, binary tree traversing, for example, you really just define a function that either traverses right or left, I haven't seen an iterative solution for it yet, and I don't think that I want to.

I really hope you liked this article and found it useful and not a boring one, lemme know your thoughts ^^

Appendices

Trampolines in PHP && optimizing flatten function



function trampoline(callable $fn)
{
    return function (...$args) use ($fn) {
        $result = $fn(...$args);

        while (is_callable($result)) {
            $result = $result();
        }

        return $result;
    };
}

function flatUnique($array, $depth = INF)
{
    $result = [];

    foreach ($array as $item) {
        if (!is_array($item)) {
            $result[] = $item;
        } elseif ($depth === 1) {
            $result = array_merge($result, array_values($item));
        } else {
            return function () use ($item, $depth) {
                return flat($item, $depth - 1);
            };
        }
    }

    return $result;
}

$flatten = trampoline('flat');

Iterative flat function

The solution from StackOverFlow also other solutions are provided there, but I find this one the most appropriate and concise.

Once again, if you're functional programming, you'd be saying yikes now as this solution is directly altering the source array, but I believe it's only for demonstration purposes.



function flatten(arr) {
  var i = 0

  if (!Array.isArray(arr)) {
    /* return non-array inputs immediately to avoid errors */
    return arr
  }

  while (i < arr.length) {
    if (Array.isArray(arr[i])) {
      arr.splice(i, 1, ...arr[i])
    } else {
      i++
    }
  }
  return arr
}

You can check my GitHub for further material and surely check my course on Functional Programming it's in Arabic for now, but maybe -if wanted- I can make an English version of it, and meanwhile, you can read a free sample of it on the github repo made for it.

Thanks for reading and happy coding 💃💜💜