Skip to content

Sugar for simulated higher-kinded types through type defunctionalization. #844

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
modulovalue opened this issue Feb 18, 2020 · 1 comment
Labels
feature Proposed language feature that solves one or more problems

Comments

@modulovalue
Copy link

Languages without higher-kinded types (HKT) have libraries for functional programming that make use of simulated HKT through [2014] Type defunctionalization (1.3).

Examples:
TypeScript: fp-ts
Swift: bow
Java: HKT & highj
Kotlin: arrow

They require quite a bit of boilerplate which does make them impractical in day to day use.

This is not a topic that I expect to receive much interest and support anytime soon. Also, I'm not an expert on that topic, but I've come across the limitations of dart when trying to employ techniques that are more common in the FP world. And with this issue I'd like to ask the language team if they could provide their thoughts on adding support (or rather sugar) for simulated HKT through type defunctionalization.

Note:
The dart specification explicitly says Dart does not, and will not, support higher-kinded types I assume that this decision has been made in the context of 'real' higher-kinded types. I want to be clear, I'm opening this issue in the context of supporting simulated higher-kinded types through type defunctionalization (or any other technique).

@modulovalue
Copy link
Author

This issue was opened three years ago. Back then, simulating higher kinded types wasn't really practical. Many features were added to Dart (static extension methods, typedefs over values, null safety) that make this possible (and even practical!) now.

Sealed classes and exhaustive matching over subtypes will make this even safer.


There are at least two packages that make use of simulated higher kinded types:

They can be consulted for advice on how to implement simulated higher kinded types in Dart.


I claim that it is now quite practical* to work with simulated higher kinded types. It involves a non trivial amount of boilerplate, but there are some cases where it is justified if more safety or generality is needed.

For any functional programmers coming across this issue, here is a short summary of what I've experienced:

  • type-safe Monads (and the ability to abstract over them) can be implemented in Dart. One should be careful not to fall into the trap of trying to implement them (in the OOP sense), but they need to be depended on explicitly as parameters because only one instance can be implemented at a time, but different ones can be passed on as arguments. (Note: the type-safety that I refer to here is not sound, but we can hide the unsoundness in a clean way, see the packages mentioned above for examples)
  • it is not only possible to implement recursion schemes in Dart (e.g. ana & cata), but also to demonstrate the deforestation capabilities of their composition (e.g. hylo).
  • Rúnar Bjarnason has a fascinating technique for composing DSLs. IIRC they are known as Object algebras. (I can't find any pointers to it now, but If the reader knows what I'm talking about, just know that you can implement them in Dart)

I plan to share examples for some them once I find a nice way to implement GADTs in Dart.

(* I would recommend having a custom code generator)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Proposed language feature that solves one or more problems
Projects
None yet
Development

No branches or pull requests

1 participant