Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/zio/zio-constraintless
An advanced library for building DSLs that allows defering the existence of type class instances until interpretation.
https://github.com/zio/zio-constraintless
scala
Last synced: about 2 months ago
JSON representation
An advanced library for building DSLs that allows defering the existence of type class instances until interpretation.
- Host: GitHub
- URL: https://github.com/zio/zio-constraintless
- Owner: zio
- Created: 2022-07-14T09:09:27.000Z (over 2 years ago)
- Default Branch: master
- Last Pushed: 2024-08-12T07:24:53.000Z (5 months ago)
- Last Synced: 2024-08-12T08:42:20.901Z (5 months ago)
- Topics: scala
- Language: Scala
- Homepage: https://zio.dev/zio-constraintless
- Size: 467 KB
- Stars: 26
- Watchers: 10
- Forks: 4
- Open Issues: 12
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
[//]: # (This file was autogenerated using `zio-sbt-website` plugin via `sbt generateReadme` command.)
[//]: # (So please do not edit it manually. Instead, change "docs/index.md" file or sbt setting keys)
[//]: # (e.g. "readmeDocumentation" and "readmeSupport".)
# ZIO Constraintless
ZIO Constraintless allows you to build programs as mere descriptions with maximum polymorphism, maximum modularity, zero abstraction leakage, and zero casting.
[](https://github.com/zio/zio/wiki/Project-Stages)  [](https://oss.sonatype.org/content/repositories/releases/dev/zio/zio-constraintless_2.13/) [](https://oss.sonatype.org/content/repositories/snapshots/dev/zio/zio-constraintless_2.13/) [](https://javadoc.io/doc/dev.zio/zio-constraintless-docs_2.13) [](https://github.com/zio/zio-constraintless)
## Introduction
It is **a Scala take on the following paper in Haskell, on parametrising the program with logical constraints at every node, without compromising modularity**
http://www.doc.ic.ac.uk/~wlj05/files/Deconstraining.pdf
An excerpt from the paper:
_"The key principle that underpins our idea is that implementation- specific constraints should be imposed at the point of use of a data type, not at the point of definition, i.e. it embodies the established principle that an interface should be separated from its implementation(s)."_
## Installation
```sbt
libraryDependencies += "dev.zio" %% "constraintless" % "0.3.2"
```
## Example
Example: https://github.com/zio/zio-constraintless/blob/master/examples/src/main/scala/zio/constraintless/examples/Expr.scala
## Context
The key to many inspectable programs such as an execution planner, a configuration DSL etc is the basic concept of "programs as descriptions", but this idea comes with limitations.
This description (or data) can easily turn out to be a Generalised ADT that can be recursive, such that compiler has to traverse through the unknown types (existential) and for the compiler to do any advanced/useful stuff with it, it needs to know more about these types.
The obvious implication of having to handle "unknown" is that, the data should hold on to informations as constraints (that are relevant to implementation) on types at the definition site. A possible solution is to compromise on parametric polymorphism, or fall back to relying unsafe/safe (relative) casting (asInstanceOf).
This naive approach imposes modularity issues, and possible runtime crashes. The reasonsing and solution is given in the above paper, and this project solves the exact problem in scala.
## Why not the Hughes schema?
It doesn't allow you to have a compiler with multiple constraints.
A few excerpts from the paper on why it doesn't work:
```scala
class Typeable p a valueP :: a → p a
```
```scala
newtype SM a = SM {fromSM :: Int}
instance IntBool a ⇒ Typeable SM a where
valueP = SM · toInt
```
```scala
newtype Pretty a = Pretty {fromPretty :: String}
instance Show a ⇒ Typeable Pretty a where valueP = Pretty · show
```
```scala
data Exp p a where
ValueE::Typeable p a ⇒ a → Exp p a
CondE ::Expp Bool→Exp p a → Exp p a → Exp p a
EqE :: Eq a ⇒ Exp p a → Exp p a → Exp p Bool
```
```scala
pretty :: Exp Pretty a → String // works
compileSM :: Exp SM a → String // works
```
However, now suppose that we wish to apply the two functions to the same expression, as in:
```scala
f :: Exp p a → . . .
f e = ...(compileSM e)...(pretty e)..
```
and that's impossible
## Documentation
Learn more on the [ZIO Constraintless homepage](https://zio.dev/zio-constraintless/)!
## Contributing
For the general guidelines, see ZIO [contributor's guide](https://zio.dev/about/contributing).
## Code of Conduct
See the [Code of Conduct](https://zio.dev/about/code-of-conduct)
## Support
Come chat with us on [![Badge-Discord]][Link-Discord].
[Badge-Discord]: https://img.shields.io/discord/629491597070827530?logo=discord "chat on discord"
[Link-Discord]: https://discord.gg/2ccFBr4 "Discord"
## License
[License](LICENSE)