> Combined with the extremely powerful compile-time reflection capabilities of D it's the closest thing I've seen to Lisp metaprogramming outside of that family of languages ...
Scala gets pretty close to LISP-level of metaprogramming support between its intrinsic support for macros[0] (not to be confused with the C/C++ preprocessor of the same name), the Scalameta project[1], and libraries such as Shapeless[2].
Not comparing Scala to D, just identifying a language with similar functionality.
0 - https://docs.scala-lang.org/scala3/reference/metaprogramming...
1 - https://scalameta.org/
2 - https://github.com/milessabin/shapeless
In C++26: more constexpr in the core languagemilessabin
shapeless
Scala2012–2025
milessabin / shapeless
shapeless
Generic programming for Scala
21Distinct people
24Mentions
0Explicit recommenders
3.4KGitHub stars
What to know before exploring
What it is
Generic programming for Scala
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- scalaz/scalaz · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year24 dated mentions
Observed mentions: 2012-03-15 20:20:06 UTC to 2025-04-24 01:39:21 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2012 | 2012-01-01 00:00:00 UTC | 2013-01-01 00:00:00 UTC | 2 | 2 | 0 |
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 6 | 2 | 4 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 0 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
shapeless: generic programming for Scala
shapeless is a type class and dependent type based generic programming library for Scala. It had its origins in
several talks by Miles Sabin (@milessabin), given over the course of 2011, on implementing scrap your
boilerplate and higher rank polymorphism in Scala. Since then it has evolved from being a resolutely
experimental project into a library which, while still testing the limits of what's possible in Scala, is being used
widely in production systems wherever there are arities to be abstracted over and boilerplate to be scrapped.
Projects which use shapeless
There is a wide variety of projects which use shapeless in one way or another ... see the
incomplete list of projects for ideas and inspiration. If you are using shapeless and your
project isn't listed yet, please add it.
Finding out more about the project
The feature overview for shapeless-2.0.0 provides a very incomplete introduction to shapeless.
Additional information can be found in subsequent release notes. If you are upgrading from
shapeless-2.0.0 you will find the migration guide useful. We're not satisfied with the current state
of the documentation and would love help in improving it. You can find an excellent guide to Shapeless here:
The Type Astronaut's Guide to Shapeless.
shapeless is part of the Typelevel family of projects. It is an Open Source project under the Apache
License v2, hosted on github. Binary artefacts are published to the
Sonatype OSS Repository Hosting service and synced to Maven Central.
Most discussion of shapeless and generic programming in Scala happens on the #shapless channel of the Typelevel
Discord. There is also a mailing list and Gitter, but these are largely dormant now that
most activity has moved to Discord. Questions about shapeless are often asked and answered under the shapeless tag on
StackOverflow. Some articles on the implementation techniques can be found on Miles's blog, and Olivera,
Moors and Odersky, Type Classes as Object and Implicits is useful background material.
Participation
The shapeless project supports the Typelevel Code of Conduct and wants all of its
channels (mailing list, Gitter, IRC, github, etc.) to be welcoming environments for everyone.
Whilst shapeless is a somewhat "advanced" Scala library, it is a lot more approachable than many people think.
Contributors are usually available to field questions, give advice and discuss ideas on the #shapeless Discord channel,
and for people wanting to take their first steps at contributing we have a selection of open issues flagged up as
being good candidates to take on. No contribution is too small, and guidance is always available.
Using shapeless
Binary release artefacts are published to the Sonatype OSS Repository Hosting service and synced to Maven
Central. Snapshots of the main branch are built using GitHub actions and automatically published to the Sonatype
OSS Snapshot repository.
Try shapeless with an Ammonite instant REPL
The quickest way to get to a REPL prompt with the latest version of shapeless on the class path is to run the
provided "try shapeless" script, which has no dependencies other than an installed JDK. This script
downloads and installs coursier and uses it to fetch the Ammonite REPL and the latest version
of shapeless. It then drops you immediately into a REPL session,
% curl -s https://raw.githubusercontent.com/milessabin/shapeless/main/scripts/try-shapeless.sh | bash
Loading...
Compiling (synthetic)/ammonite/predef/interpBridge.sc
Compiling (synthetic)/ammonite/predef/replBridge.sc
Compiling (synthetic)/ammonite/predef/DefaultPredef.sc
Compiling /home/miles/projects/shapeless/(console)
Welcome to the Ammonite Repl 1.6.8
(Scala 2.13.1 Java 1.8.0_212)
If you like Ammonite, please support our development at www.patreon.com/lihaoyi
@ 23 :: "foo" :: true :: HNil
res0: Int :: String :: Boolean :: HNil = 23 :: "foo" :: true :: HNil
@ Bye!
%
shapeless-2.3.3 with SBT
To include the Sonatype repositories in your SBT build you should add,
resolvers ++= Seq(
Resolver.sonatypeRepo("releases"),
Resolver.sonatypeRepo("snapshots")
)
Builds are available for Scala 2.11.x, 2.12.x and 2.13.x. The main line of development for
shapeless 2.3.3 is Scala 2.13.2.
scalaVersion := "2.13.5"
libraryDependencies ++= Seq(
"com.chuusai" %% "shapeless" % "2.3.3"
)
For using snapshots of Shapeless you should add,
scalaVersion := "2.13.5"
libraryDependencies ++= Seq(
"com.chuusai" %% "shapeless" % "2.4.0-SNAPSHOT"
)
shapeless-2.3.3 with Maven
shapeless is also available for projects using the Maven build tool via the following dependency,
<dependency>
<groupId>com.chuusai</groupId>
<artifactId>shapeless_2.13</artifactId>
<version>2.3.3</version>
</dependency>
Older releases
Please use a current release if possible. If unavoidable, you can find usage information for older
releases on the shapeless wiki.
Building shapeless
shapeless is built with SBT 1.3.10 or later, and its main branch is built with Scala 2.13.2 by default but also
cross-builds for 2.11.12 and 2.12.12.
Contributors
Alex Zorab alec.zorab@gmail.com @aleczorab
Alessandro Lacava alessandrolacava@gmail.com @lambdista
Alexander Konovalov alex.knvl@gmail.com @alexknvl
Alexandre Archambault alexandre.archambault@gmail.com @alxarchambault
Alistair Johnson alistair.johnson@johnsonusm.com @AlistairUSM
Allison H. allisonhb@gmx.com
Alois Cochard alois.cochard@gmail.com @aloiscochard
Andreas Koestler andreas.koestler@gmail.com @AndreasKostler
Andrew Brett github@bretts.org @Ephemerix
Aristotelis Dossas teldosas@gmail.com @teldosas
Arya Irani arya.irani@gmail.com @aryairani
Ben Hutchison brhutchison@gmail.com @ben_hutchison
Ben James ben.james@guardian.co.uk @bmjames
Brian McKenna brian@brianmckenna.org @puffnfresh
Brian Zeligson brian.zeligson@gmail.com @beezee
Bryn Keller xoltar@xoltar.org @brynkeller
Carlos Quiroz @carlosmquiroz
Chris Hodapp clhodapp1@gmail.com @clhodapp
Cody Allen ceedubs@gmail.com @fourierstri
Read the full README on GitHubWhat Hacker News says
24 sourcesAnd thus Shapeless (https://github.com/milessabin/shapeless) was born.
In Iterate over Parameter Packs in Swift 6.0That largely depends on the type system. Languages like Haskell and Scala which have much more powerful type systems than C/Java/Go/etc absolutely do allow you to do those sorts of things. It is a bit harder to wrap your head around to be sure and there are some rough edges, but once you get the hang of it you can get the benefits of static typing with the flexibility of dynamic typing. See https://github.com/milessabin/shapeless or a project that I've been working on a lot lately https://github.com/zio/zio-schema.
In Six Years of Professional ClojureThis is just making clear and easy to use something that people did using some type level magic (see shapeless Witness).
Something that people used through ugly hacks becoming part of the language natively in a easy to use and understand (and faster to compile) way sounds very much like pragmatism to me.
Here is the source code to Witness (and other singleton stuff in shapeless) https://github.com/milessabin/shapeless/blob/main/core/src/m...
In Scala 3.0As someone who has spent a lot of time diving deep into Scala (I worked on compiler related semantic tooling for scalameta, worked on a experimental parallelizable Scala compiler, and even have a single commit in this release from almost four years ago LOL), and who more recently has been working with TypeScript, I find this really interesting and agree in some ways.
Scala 2.x already had path-dependent types, which combined with implicits and type inference were technically sufficient to implement versions of of the dependent function types we have now in 3.x. In my opinion, how you did this previously could get really clunky (See e.g. hlist mapping in https://github.com/milessabin/shapeless/blob/8933ddb7af63b8b...). Lots of things that frankly felt like casting magic spells, and there were sometimes fragile and weird bugs especially wit
Read the rest
h how implicits were resolved, see e.g. https://github.com/scala/scala/pull/6139.
The native type-level meta-programming coming in 3.x along with a lot of streamlining of the underlying type system and implicit resolution rules (e.g. https://github.com/lampepfl/dotty/pull/5925) could help a lot.
This is just one example of a more advanced feature, but there are lots of things like this that changed in Dotty (maybe the most interesting is the DOT calculus that makes a better backbone for the type system). I don't know what tooling for Scala 3.x looks like, but even Intellij's frankly amazing Scala plugin broke down sometimes for 2.x.
After using TypeScript, I just personally enjoyed the experience better. Technically Typescript's type system is equally as powerful as Scala's, but the primitives for expressing more complicated types just seem much easier compared to the path-dependent stuff you would need to do in Scala.
I was amazed to find stuff like this https://github.com/aws-amplify/amplify-js/blob/dedd5641dfcfc... in mainstream wide usage. I'm not even sure how you could write these type of transformations as well in any version of Scala. I suppose maybe records work, or in this specific case there are functional patterns that are preferred.
Caveat, I haven't followed Dotty for a couple years now, so I could be missing a lot. Regardless, I have really enjoyed the tooling around Typescript as well as the design. The real-world usage of more complicated dependent types (and there are good uses IMO) have been more fluent and easier to understand, and less dependent on tricky behavior like for implicits.
VS Code's tools are really magical, and I hope with some of the amazing underlying work done in Dotty the Scala developer experience could look more like that.
I'm not sure where is the line between extensive and basic knowledge. Here is my more detailed exposure:
In commercial context:
* Of strongly typed ones only Scala (with [shapeless]). Can reluctantly throw in Kotlin as well for it's amazing structured concurrency.
In non-commercial context:
* Went through a few chapters of [Software Foundations] doing Coq proofs.
* Worked through most of the [Types and Programming Languages] (writing typecheckers in Ocaml)
* 3 services in Haskell (1 on Scotty, 2 on Servant). Loved persistent+esqueleto for the ORM layer, disliked Opaleye.
* 2 projects in PureScript (1 with Halogen, 1 with React bindings).
* 1 project in ReasonML (Ocaml).
-
> I am afraid there is no way back for me
I see where you are coming from. In my case I can alternate between "I want all invariants properly expressed and checked" and
Read the rest
"I just want to ship that barely-working piece of junk and iterate on it". I learned to adjust depending on organization needs. IMO, for many orgs, especially startups/scaleups, the latter is often the more fitting way. With that in mind, I'm willing to trade the guiding hand of great type systems for other productivity aspects (amazing runtime and cohesive web framework in Elixir's case).
[shapeless]: https://github.com/milessabin/shapeless
[Software Foundations]: https://softwarefoundations.cis.upenn.edu/
[Types and Programming Languages]: https://www.cis.upenn.edu/~bcpierce/tapl/
Macros are useful for defining things that don't make sense "within" our programming language. For example, I write a lot of Scala code, and that language has a bunch of types like 'Tuple2[A, B]', 'Tuple3[A, B, C]', 'Tuple4[A, B, C, D]', etc. As a programmer we can see that these are all instances of some higher-level pattern 'TupleN[T1, T2, ..., TN]' but Scala has no idea about that; hence we can't write code which, for example, sums the first N elements of any tuple.
Actually, we can but it's not safe: Scala's tuples implement a 'Product' interface which we can use to loop through the values, but this loses a lot of type safety (looking up values via Product will upcast them to type 'Any'; our function's signature will ask for a 'Product' rather than specifically for tuples of numbers of at least a certain length, etc.)
Macros generate
Read the rest
code at each of their call sites, which lets us automatically translate our 'higher level language' (e.g. 'Tuples of different lengths') into the 'real language' (e.g. Scala). For example, we can have a macro that translates 'tupleSum(5, 10, foo)' into a call like 'tupleSum5_10(foo)', where the function 'tupleSum5_10' is hard-coded to sum the first 5 elements of a Tuple10 (and is therefore acceptable to Scala, since it doesn't try to abstract over tuple lengths), e.g.
def tupleSum5_10[T1, T2, T3, T4, T5](t: Tuple10[Int, Int, Int, Int, Int, T1, T2, T3, T4, T5]): Int =
t match {
case (x1, x2, x3, x4, x5, _, _, _, _, _) => x1 + x2 + x3 + x4 + x5
}
Of course, we don't want to be writing functions like 'tupleSum5_10' manually. Hence we can use another macro to define these functions! For example, the above might be generated by a macro call like 'defTupleSum(5, 10)'. If we run this macro in a loop, we can define all of the sum functions for tuples up to, say, Tuple20.
If we provide this in a library, users can treat tuples in a more high-level way. Since each macro call just generates some boilerplate Scala code, the result will be type-checked, etc. to make sure we've not done anything dodgy, e.g. since a call like 'tupleSum(5, 10, foo)' expands to 'tupleSum5_10(foo)', Scala will check whether 'foo' matches the type 'Tuple10[Int, Int, Int, Int, Int, T1, T2, T3, T4, T5]'.
I think the most famous use of macros in Scala is Shapeless https://github.com/milessabin/shapeless/wiki/Feature-overvie... (although I've not personally used it)
Note that the exact same problem with tuples happens in Haskell too, which can also be worked around using Haskell's macro system (TemplateHaskell).
Yeah, I figured it might not be currently possible. I was thinking about something like Scala HList[1], which provides a map/flatMap (which enables for-loop) method for tuples (among other functionality).
[1] https://github.com/milessabin/shapeless/wiki/Feature-overvie...
In Modern C++ gamedev: thoughts and misconceptionsI was initially skeptical of Scala when I landed my first Scala gig a few years ago, but now I'm really glad I picked it. Simple things like pattern matching and immutability are amazing, and Implicits + Macros enables some awesome libraries like Shapeless[1], Chimney[2] which solves real business problems in a succinct and type-safe way.
Very excited about what's coming in Scala 3
* Lots of improvements to make the language simpler and easier to work with
* Integrating some tried-and-true patterns from the current Scala ecosystem directly into the language
* First-class tooling to solve some long-standing issues in the ecosystem (binary compatibility)
The team behind Scala 3 has done a tremendous job. Along with the whole movement of better tooling that's happening in the Scala ecosystem right now, I think the language will have a fun an
Read the rest
d productive future!
[1]: https://github.com/milessabin/shapeless
[2]: https://scalalandio.github.io/chimney/
I would recommend that you definitely look into Scala.
The language that was fundamentally designed to be "scalable" with and/for frameworks. Check this resource for more information.
- https://scalameta.org/
- https://speakerdeck.com/itakeshi/metaprogramming-in-scala-th...
- https://geirsson.com/post/2016/02/scalameta/
- https://github.com/milessabin/shapeless
- https://vimeo.com/217863345
In Ask HN: What metaprogrammable language do you/would like to use?I have no experience with C++, so don't know how it compares.
There is some truth in the statement, in that a Scala team will often gradually adapt more advanced features of the language. I wouldn't call them different languages, but rather say Scala is a "Java N+5" in that sense. Java 8 is objectively much more advanced than Java 4, but it's very much the same language and a Java 4 dev will get used to and see value in Java 8's new features. Same with Scala .
The main schism is what some people jokingly call the "compiling Haskell with scalac" crowd. They are hardcore functional programmers who value FP ideals like category theory over all else. There even is a forked Scala compiler [1] (luckily the fork and mainline reconciled, and now every change in the fork is a PR for mainline). The crowd is mostly exemplified by libraries like Scal
Read the rest
aZ [2] and to a lesser extent Cats [3] and shapeless [4]. Some even advocate replacing the whole Scala standard library with their own. Can you at that point still say you're using Scala? You can probably read that I do not personally like that style, and consider it a detriment to the community†, so consider my statements in light of that opinion.
The main reason why I don't like the style is that Scala is not powerful enough when compared to Haskell or Julia, requiring lots of magic and boilerplate to make it work. Maybe this will ultimately be resolved, as there have been gradual improvements over versions, and this will be the final niche Scala will occupy long-term, as I have not seen any contenders yet.
† I have tremendous respect for the maintainers of the library and their skills, but I don't think the schism is healthy.
[1] https://typelevel.org/scala/
[2] https://github.com/scalaz/scalaz
[3] https://github.com/typelevel/cats
[4] https://github.com/milessabin/shapeless
Haskell and Scala are safer than TypeScript... but not by too much :) The only major safety feature lacking in TypeScript are variance annotations and proper variance for functions, which are bivariant WRT their arguments. Short demonstration of the problem:
// this should not be assignable, functions should be
// contravariant WRT arguments, so if o2 is subtype of o1
// then F1 is subtype of F2, which means you can't assign
// a value of type F2 to F1: there are functions in the
// set of functions F2 that don't belong in the subset F1
type O1 = { a: string; b: string }
type O2 = { a: string; b: string; c: string }
type F1 = (o: O1) => string
type F2 = (o: O2) => string
// should not compile!
let f: F1 = (o: O2) => { return o.c.toString() }
f({a: '1', b: '2'}) // throws at run time (o.c undefined)
Other than t
Read the rest
hat, TypeScript has been pretty safe since the addition of "strictNullChecks".
Haskell and Scala have algebraic datatypes (or case classes) which make it easier to model data (especially in Haskell where the syntax is really nice). TypeScript also supports disjoint unions (union of several types with a tag field that has a concrete string value as the type) and control flow analysis, so with some effort it can provide "idiomatic" JS-style ADTs. Haskell and Scala can do exhaustiveness checks, making sure you've covered all the cases. TS can also sort of do that (when strictNullChecks are on):
type T1 = { tag: 't1', value: string }
type T2 = { tag: 't2', value: number }
type T3 = { tag: 't3' }
type T = T1 | T2 | T3
function f(t: T):string {
switch (t.tag) {
case 't1': return t.value;
case 't2': return t.value.toString()
// Compiles only if you uncomment this line.
// Otherwise inferred return type string|undefined is
// incompatible with specified return type string
//case 't3': return 'N/A'
}
}
Not as pleasant or as general as Haskell, but better than most other mainstream languages.
Both Haskell and Scala have higher kinded generics, something that TypeScript still lacks. This means importing category theory concepts in TypeScript is pretty much impossible. The problem isn't just with category theory though; the need to parameterise generic types with other generic types as type arguments can come up everyday JS code too. For example, a library that accepts a promise constructor as an argument is parameterized by a generic type [1]
Before v2.1 TypeScript already had some powerful features for working with record types, such as record unions and intersections. With mapped types introduced in 2.1 however, you could say it surpasses Haskell and Scala in this regard - if not with features, then at least with pleasantness / ease of use. I believe its possible to achieve the same things in Haskell with vinyl [2][3], but those are definitely not Haskell's native records. Not sure if Scala's shapeless [4] can provide something similar (the answer is probably yes).
Haskell has type classes, and Scala can provide the "equivalent" via implicits+traits. Both of these allow a very nice and generic style of programming with implementation flexibility (you can write new typeclass instances for old code). TypeScript has structural interfaces, which offer some flexibility compared to nominal interfaces: you can write an interface that is a subset of old code, then use both old and new code under that interface without modifying the old code. Still, its not as flexible as typeclasses (the implementation must already be a subset of the original old code). They also can't offer the return-type-based implementation selection that typeclasses can.
Of course, Haskell and Scala both have various type / macro / template superpowers that TypeScript doesn't have and isn't likely to ever have. For everyday programming though, the above list should cover the vast majority of interesting features.
[1]: https://github.com/Microsoft/TypeScript/issues/1213
[2]: https://hackage.haskell.org/package/vinyl-0.5.2/docs/Data-Vi...
[3]: https://hackage.haskell.org/package/vinyl-0.5.2/docs/Data-Vi...
[4]: https://github.com/milessabin/shapeless/wiki/Feature-overvie...
I've tried working in an FP style in the "multiparadigm" languages you've mentioned, but it's hard, really hard. Well actually, the irony is that JavaScript is the one that's bearable and that's because (1) you can find some Javascript libraries that are doing FP and (2) it's very flexible.
Static languages such as Java and C# are not OK though. For one they lack features that are essential for statically typed languages. For example higher kinded types is an essential feature for FP. Without that you can't build libraries of reusable FP stuff. Comparing it with Scala for example you can't build Scalaz or the newer Cats or Shapeless [1].
The other problem is that FP programming languages come with FP libraries. You can't underestimate the importance of having good implementations for persistent collections be the default.
On having "no si
Read the rest
de effects", that's not what FP is about. After all, without side-effects you couldn't get any output out of a program. FP is about encoding those side-effects in types and abstractions you can reason about, or in other words it's about controlling side-effects. Haskell developers are fond of their IO monads. FRP is another way of doing that, being particularly good at dealing with user interfaces. And for example FRP-related libraries that were born by playing to the strengths of the mainstream languages we are dealing with are Facebook's React and Microsoft's Rx.
BTW, this is one of the best books on functional programming available today: http://www.manning.com/bjarnason/
[1] https://github.com/scalaz/scalaz, https://github.com/non/cats, https://github.com/milessabin/shapeless
Travis Brown has written up some great articles on advanced Scala topics and this one does not disappoint. Well done and worth the read.
Some may find the Shapeless feature overview[1] a good read as well. And for people interested in history, I found Mr. Sabin's announcement of Shapeless[2] to be both interesting and valuable for its links related to higher-kinded programming topics.
I also found "learning Scalaz"[3] a very good read, with the page discussing Isomorphisms[4] relevant to Mr. Brown's article.
1 - https://github.com/milessabin/shapeless/wiki/Feature-overvie...
2 - http://milessabin.com/blog/2011/12/19/shapeless-preview/
3 - http://eed3si9n.com/learning-scalaz/
4 - http://eed3si9n.com/learning-scalaz/Isomorphisms.html
In Type classes and generic derivationYou can do it in Scala too (cf. https://github.com/milessabin/shapeless/wiki/Feature-overvie...).
In Opaleye’s sugar on top: SQL in the type systemShowing the 15 most recent of 24 sources. Enable JavaScript to search and browse every indexed mention.