Module VS Object based ADTs

[sahilsehwag]

I am planning on implementing a functional library in another ecosystem instead of javascript. I know fp-ts is built by pretty serious FP veterans. I would love to know their detailed reasons as to why they went with first approach.

Context:

• There are two ways to go around and implement an ADT in typescript
• First is what fp-ts did, ie module based implementation where each function of ADT is exposed from module and we import whichever map we want to use based on what ADT we are using
• Second approach is what people like Brian Lonsdorf demonstrated in their talks, videos and courses, where we are creating a function that returns an object with the contained data and ADT functions as methods.
• To avoid mutation, for each operation we return a new object.
• I know there are multiple benefits we can see in module approach over object approach like probably more memory efficient, easier typing, more functional style by using composition instead of dot chaining and so on.
• But one thing that entices me for the object approach is that people can do both dot chaining and pipe based composition styles, since we can expose a single map function that just calls the map method of ADT. This way consumption becomes arguably simple, since now instead of multiple function imports with the same name, I can do a single map import and it will handle the polymorphism part.

I would love to know your reasoning/rationale/thoughts behind these 2 approaches, and If there is a way to implement this form of polymorphism, if I go with the module based implementation. And In your opinion, if the second approach would make more sense in an untyped language.

I would love your input in terms of design considerations, ie if there is any inherent benefit when considering expressive power that module approach has over object approach ie if there are certain things that we could not just achieve using object approach.

Thank you for your great work in TS ecosystem

[adrian-gierakowski]

If you put all methods on an object you cannot tree-shake away the methods your program doesn’t use. This might be of interest: https://dev.to/effect-ts/the-case-for-ts-18b3

[sahilsehwag]

@adrian-gierakowski Thank you for the response. Few points I would like to highlight:

• First of all that was a great article, and provided a balanced comparison between two approaches, highlighting pros and cons of both approaches.

• Your point about tree-shakeable ness of object approach, which I completely agree with. But this is an ecosystem issue, since javascript operate in the realm of browsers where asset size is a pretty big constraint and optimizations like code splitting and bundling optimizations like tree-shaking is a necessity.

• I would like to avoid any ecosystem specific nuances, and focus more on design comparisons between 2 approaches.

• The article did mention some great points like unable to add extension methods to existing classes from an external source. Although this is a great point that I didn't consider but its an implementation detail related to language limitations(ie ecosystem), since some languages like C# do provide mechanisms to extend objects without module augmentations.

• But I do like this point, since the ecosystem I am going for also makes it difficult to extend classes externally.

• Another point I would like to focus on is if there are ways to implement this kind of polymorphism in module approach, where for example we can expose a single map that handles the polymorphic aspect of which map to run.

• One more thing, If you have a stash of great articles that provides great design insights in terms of functional programming in javascript/typescript ecosystem. Please do send them my way, that would be blast to go through :)