The default replacement string is "", so you can just return x.replace " "

Ah that makes sense. Thank you both.

Maybe the greater question is - is newtype LengthList simple a wrapper?

Yep! It does little more than allow us to define new instances which differ from the inner type.

Also... is instance Ord a... defining how LengthList will respond to the functions defined by the Ord typeclass?

Precisely.

x and y are of type [a], not LengthList a.

Consider these two ways of writing a function:

foo :: LengthList a -> ...
foo x = ...

and

foo :: LengthList a -> ...
foo (LengthList x) = ...

In the first example, the argument is simply bound to the identifier "x"; hence, x has type LengthList a. In the second example, however, we pattern-match on the argument, and bind the contents of the LengthList to the indentifier "x". So in the second example x has type [a].

Hope that helps.

What allows you to call length on x and y, if they are of type LengthList? Why do they still respond to list functions?

Maybe the greater question is - is newtype LengthList simple a wrapper?

Also... is instance Ord a... defining how LengthList will respond to the functions defined by the Ord typeclass?

Thank you for your suggestions.
I absolutely missed that I can ignore the x in the last pattern.

I will check how the order of the pattern matching influences performance in bigger functions or even applications. Thank you for the hint, I never thought of it so far.

This is a really good solution but two suggestions.

You can speed the execution up by performing the error check as the final pattner. This prevents you from checking if the list is empty every itteration. This is a small issue in this example but is still good practice.

In your last pattern, you should not be assigning x to a variable. Instead use _ to avoid an unnecessary assignment. Again, this is pretty minor in this example but useful as your code grows.

I definitely suggest you make this an iterative process instead of a recursive process. The recursive process will deplete the stack very quickly due to the way the number of steps and memory consumption increases with the number. This might be a shorter (code wise) recursive solution but if you use recursion with an iterative process it will ensure that the stack is never depleted.

I absolutely agree with this. I think this would make for much more interesting algorithms, and a more realworld type scenario.

Please read this MDN article on the Function.prototype.bind(). I didn't get it at first either, but after reading that article it made perfect sense. This is a very elegant and useful solution.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/bind

I completely agree. As a developer you should always know exactly what are the expected results of your code. This question isn't descriptive enough, and very difficult to write valid code for.