From c5b61d2f46ac19bf511197f3a537c4be0f47df33 Mon Sep 17 00:00:00 2001
From: Eduardo Julian
Date: Fri, 27 Aug 2021 20:59:34 -0400
Subject: Updates to the Ruby compiler.

---
 .../the_lux_programming_language/appendix_f.md     | 68 ++++++++++++++++++++++
 1 file changed, 68 insertions(+)
 create mode 100644 documentation/book/the_lux_programming_language/appendix_f.md

(limited to 'documentation/book')

diff --git a/documentation/book/the_lux_programming_language/appendix_f.md b/documentation/book/the_lux_programming_language/appendix_f.md
new file mode 100644
index 000000000..b977623a8
--- /dev/null
+++ b/documentation/book/the_lux_programming_language/appendix_f.md
@@ -0,0 +1,68 @@
+# Appendix F: Implicit polymorphism
+
+If you've used Lux's interfaces and implementations already (with the `\` macro), you've probably noticed that you need to pass around the specific implementations you need every time you want to call some interface's method, or access some constant value.
+
+That can become tiresome if you need to do it all the time, and specially if you come from languages that do method-selection for you automatically.
+
+Object-oriented languages do polymorphism in an easy way, because they link objects to the method table of their associated classes, and when you call a method on an object, the run-time system can figure out where the code that needs to be run lies within the program's memory.
+
+Languages with type-classes, such as Haskell, perform that look-up at compile-time, by using the type-information present in the compilation context to figure out which implementation (or _instance_) of a type-class is suitable to each particular circumstance.
+
+Lux, on the other hand, forces you to be specific about the implementations that you're going to use.
+
+While that gives you a level of power and flexibility you wouldn't otherwise have in other languages, it also introduces the problem that when what you want doesn't warrant that level of power, you have to pay the tax it involves nonetheless.
+
+But, that sounds like a raw deal.
+
+Why do you have to pay for something you're not taking advantage of?
+
+Clearly, there is an asymmetry here.
+
+It is a feature that is most useful in the few instances when you want full power.
+At any other point, it's a hindrance.
+
+Well... there is an alternative.
+
+The Lux Standard Library includes a module called `library/lux/type/implicit`, which provides a macro called `\\`, that serves as an easier-to-use alternative to the `\` macro.
+
+What it does is that instead of requiring the implementation you want to use, it only requires the name of the function you want to call and the arguments.
+
+Then, at compile-time, it does some type-checking and some look-ups and selects an implementation for you that will satisfy those requirements.
+
+That implementation can come from the local-var environment, from the definitions in your own module, or even from the exported definitions of the modules you're importing.
+
+That way, you can use `\` whenever you need precision and power, and use `\\` whenever you're doing more lightweight programming.
+
+Fantastic!
+
+This is how you'd use it:
+
+```
+... Equality for nats
+(\ nat.equivalence = x y)
+## vs
+(\\ = x y)
+```
+
+```
+... Equality for lists of nats
+(\ (list.equivalence nat.equivalence) =
+   (list.indices 10)
+   (list.indices 10))
+... vs
+(\\ = (list.indices 10) (list.indices 10))
+```
+
+```
+... Functor mapping
+(\ list.functor each nat.inc (list.indices 10))
+... vs
+(\\ each nat.inc (list.indices 10))
+```
+
+---
+
+Thanks to implicit polymorphism, you don't have to choose between power and ease of use.
+
+Just do a static-import of the `library/lux/type/implicit` module, and you'll get the `\\` available and ready for action.
+
-- 
cgit v1.2.3