From 27b2b1bcc6d454e8e79afc00478666eedd9751c4 Mon Sep 17 00:00:00 2001 From: Elijah Rippeth Date: Sun, 11 Nov 2018 11:09:02 -0500 Subject: [PATCH 1/3] add RFC for HKTs --- text/0060-hkts.md | 50 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 text/0060-hkts.md diff --git a/text/0060-hkts.md b/text/0060-hkts.md new file mode 100644 index 00000000..58f1910b --- /dev/null +++ b/text/0060-hkts.md @@ -0,0 +1,50 @@ +- Feature Name: higher kinded types +- Start Date: 2018-11-11 +- RFC PR: +- Pony Issue: + +# Summary + +Higher kinded types (HKTs) are a way to refer to generic types which are themselves generic. + +# Motivation + +By supporting HKTs, Pony code could be made more generic by defining interfaces that support HKTs instead of concrete polymorphic types. This allow for strong static functional programming using Pony. + +# Detailed design + +Implementation of HKTs would likely be based on the Scala implementation. An example usage in Pony may be: + +``` +interface Functor[F[_]] + fun map[A, B](f: {(A): B}): F[B] +``` + +It seems like `[_]` could reference to any `_: Any val`. + +# How We Teach This + +Luckily, HKTs are pretty familiar to people using functional programming and are potentially transparent to those not using it. As such, reusing terminology is possible. + +The guides, especially those which discuss generic types, would need to be reworked. This should be as simple as introducing generic types which also have generic parameters. + +# How We Test This + +If Pony internals can be ported to use HKTs, this indicates an acceptance criteria. Inspiration can be taken from [typelevel Scala libraries](https://typelevel.org/projects/) with support for HKT. + +# Drawbacks + +Why should we *not* do this? Things you might want to note: + +tl;dr: scary for users and maintainers + +If this is accepted, it could (and perhaps should) be used throughout the implementation of Pony to write more generic code. This is risky. It also can make the code (on first blush) a bit more opaque to those not familiar with HKTs. + + +# Alternatives + +By not integrating HKT support, we would need to write more concrete code. More code means more bugs and more maintenance. + +# Unresolved questions + +What parts of the design are still TBD? From 1434fb2628079c27e917686e2219ba988e508b60 Mon Sep 17 00:00:00 2001 From: Elijah Rippeth Date: Sun, 11 Nov 2018 11:10:07 -0500 Subject: [PATCH 2/3] Update 0060-hkts.md --- text/0060-hkts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0060-hkts.md b/text/0060-hkts.md index 58f1910b..8d27a151 100644 --- a/text/0060-hkts.md +++ b/text/0060-hkts.md @@ -47,4 +47,4 @@ By not integrating HKT support, we would need to write more concrete code. More # Unresolved questions -What parts of the design are still TBD? +None From 1b06eeb9be9772f740b486de1dda087c6b35e2e7 Mon Sep 17 00:00:00 2001 From: Elijah Rippeth Date: Sat, 5 Jan 2019 15:39:53 -0500 Subject: [PATCH 3/3] Update 0060-hkts.md --- text/0060-hkts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0060-hkts.md b/text/0060-hkts.md index 8d27a151..b212a346 100644 --- a/text/0060-hkts.md +++ b/text/0060-hkts.md @@ -17,7 +17,7 @@ Implementation of HKTs would likely be based on the Scala implementation. An exa ``` interface Functor[F[_]] - fun map[A, B](f: {(A): B}): F[B] + fun map[A, B](f: {(A): B}, fa: F[A]): F[B] ``` It seems like `[_]` could reference to any `_: Any val`.