Comments (4)
I probably will not add support for record subtyping (or subtyping in general), partly because Dhall is an experiment in designing a language without any subtyping at all. For example, this is the same reason that Dhall requires explicit type abstraction and type application.
However, I would be open to adding language features that make it easier to explicitly convert between records where a subtyping relationship could exist. For example, Nix has this sort of feature with the inherit
keyword that lets you easily project out a subset of fields and Dhall could add something similar.
I also like the idea of a type-level record union operator, although I would like to reserve the symbol \/
for use with sum types.
from dhall-haskell.
Okay I wholeheartedly support the idea of avoiding all forms of subtyping as an experiment :)
If I understand inherit
correctly, that does not solve the use case of having a larger
config file where additional fields are ignored, right? The use case I have in mind is something like:
$ cat > config
{
one = 1,
two = 2,
three = 3
}
Now imagine this config
file as being shared by two libraries that use dhall
to configure themself.
However, both of them need only a subset of the actual config:
$ cat > schema1
{ one : Integer, two: Integer }
$ cat schema2
{ two : Integer, three : Integer }
It would be cool, if there was something that allows you to have config
as-is, where it represents a set of all required attributes, without forcing you to split them.
I think I'll have to think about something that makes this possible without subtyping.
from dhall-haskell.
Anyhow, I'll think a bit about this, I close this for now, cheers!
from dhall-haskell.
You should check out "row polymorphism" which is a solution that works very well for modeling extensible records in languages with type inference. In languages without type inference (like Dhall) it is a little trickier but still possible and I'll sketch one approach of how it might be done in Dhall.
The basic idea is that a function that only depends on a subset of fields would like something like this:
-- example
λ(fields : Fields) → λ(record : { foo : Natural, bar : Natural | fields }) → record.foo + record.bar
... where Fields
would be a new kind (i.e. Fields : Kind
) and fields
would be a set of field types. For example, if you wanted to apply this function to a record of type { foo : Natural, bar : Natural, baz : Bool }
then you would do something like:
./example {{ baz : Bool }} { foo = +2, bar = +2, baz = True }
... where {{ baz : Bool }}
is a hypothetical new syntax for specifying additional fields.
You might wonder why we don't use a hypothetical type-level union operator like the one your proposed to accomplish the same thing. The issue is that you get something like this:
-- Here I'm overloading `∧` as type-level union, too
λ(fields : Type) → λ(record : { foo : Natural, bar : Natural } ∧ fields) → record.foo + record.bar
... which should not type-check because the compiler can't verify that the fields
argument will be the type of a record.
So I think it is possible to implement something like this in Dhall if you don't mind having to explicitly specify unused fields. However, I'd probably prefer providing a way to project out desired fields since then you only have to specify the fields you want to keep instead of the fields you want to ignore.
from dhall-haskell.
Related Issues (20)
- Please report symlink contents for `Error: Missing file` HOT 2
- Error generating docs
- combine `let` bindings in `dhall format` HOT 1
- Support request for `aeson` 2.2 in `dhall` HOT 2
- dhall-to-yaml does not properly quote strings HOT 1
- Can not install dhall-lsp-server HOT 2
- Allow hnix 0.17
- Hackage build failed for dhall-toml-1.0.3
- Get back into Stackage Nightly with GHC 9.8 HOT 1
- Missing binaries in release HOT 1
- Hackage release for dhall-lsp-server HOT 1
- Build failure on GHC 9.8.1: 'Illegal invisible type variable binder'
- Report imports HOT 2
- dhall-docs: Prelude.head: empty list
- Suggesting a new construct for dealing with optional fields in Dhall defaults
- dhall-json bound on aeson can be relaxed
- Questions regarding the right strategy for upgrading to ghc-9.8
- Build failure on macos-latest stack.yaml HOT 3
- Is there a specification for dhall-to-{json,yaml} and {json,yaml}-to-dhall? HOT 1
- Pretty-printer: escape unprintable characters HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dhall-haskell.