This adds four new sections to the page after the live demo which highlight
the common themes that I notice people use when communicating the value of
Dhall to others on social media:
* The first section emphasizes the element of delight in using the language for
people who are into elegance and quality
* The second section focuses on more pragmatic people who are sick of YAML and
just want a reasonable alternative that they can convince their manager to
adopt
* The third section appeals to the LangSec crowd that wants an uncompromising
and secure foundation for what they are buliding
* The last section targeted at the skeptic who thinks that Dhall is an ivory
tower language not suited for real-world problems.
The second crowd (YAML emigrants) is the audience that I'm targeting the
most strongly at the moment, but I didn't want to lead with a negative reason
adopt by focusing on the limitations of YAML, so I put the section on delight
first so that we could start with a more positive tone.
This adds three new Nix build products:
* `try-dhall-static` - The static assets for "Try Dhall"
* `try-dhall-server` - A script which serves the static assets for local
debugging
* `tarball-try-dhall` - A tarball of the static assets
This is powered by a new small `dhall-try` package which is also included
in this change.
The motivation for this change is:
* To catch build failures in downstream packages whenever we make a breaking
change to the `dhall` API
* To reduce the amount of work I need in order to cut a release for all of
these packages
* To better share Nix/CI-related logic between the projects
Note that I have not yet migrated `dhall-nix` in. I'm waiting for
https://github.com/dhall-lang/dhall-nix/issues/17 to be fixed since
`dhall-nix` is incompatible with later versions of `megaparsec` due to
`hnix`.
Fixes https://github.com/dhall-lang/dhall-haskell/issues/645
Fixes https://github.com/dhall-lang/dhall-lang/issues/216
This updates the `README` with the following changes:
* Points to the language-agnostic `README` in the `dhall-lang` repository
* Retains only Haskell-specific sections of interest
* Removes the embedded LICENSE now that GitHub auto-recognizes the project
license (#644)
* Changes the Quick Start instructions to use Nix
* Adds instructions for project development using Nix
The latter two points entailed refactors to the Nix logic to simplify the
user experience:
* `default.nix` was moved to `shared.nix` and replaced with a new `default.nix`
that works out-of-the-box with `nix-build`
* There is a new `nix/test-dhall.nix` which users can use to create a
`nix-shell` with Dhall as a dependency
... as requested by @jneira so that Dhall will continue to work as a
dependency of Eta, which is built using GHC 7.10.3
This adds CI support for testing the build against GHC 7.10.3 and also
fixes issues building against that GHC version that were caught in the process
`readDirectory` was upstreamed into `nixpkgs` as `packagesFromDirectory`
and now that we are on a new enough revision of `nixpkgs` we can
`packagesFromDirectory`
The haskell package overrides section of `overlayDynamic` was shadowing
the corresponding overrides in `overlayShared`. This change fixes that
so that they correctly stack.
This adds a new `dhall-static` target that builds a fully static `dhall`
executable that can be run on any Linux machine (i.e. it is a relocatable
executable that is completely dependency free). That in turns implies
that even though it is built with Nix it doesn't require that the user
installs Nix to run it (i.e. no dependency on the `/nix/store` or a
Nix installer). Just copy the standalone executable to any Linux machine
and it's good to go.
This based on the following work of @nh2:
* https://github.com/NixOS/nixpkgs/issues/43795
* https://github.com/dhall-lang/dhall-lang/issues/192#issuecomment-406134451
This also bumps the version of `nixpkgs` used for the normal (non-static)
Dhall build to be the closest revision on `nixpkgs` `master` as the one
used by @nh2 in his work. Once that work is merged into `nixpkgs` `master`
then both builds can use the same revision from `nixpkgs` `master`.
* Benchmark Prelude files
* Add issue 108 example
* Some cleaning up
* Remove printing of files
* Add bounds
* Clean cabal formatting
* Add benchmark examples to extra source files
* Add Nix support for benchmarks
* This doesn't (yet) run or build the benchmarks in CI due to the long time
to execute all of them, but this does add them to the `shell.nix` so that
they can be run using local development
The long-term motivation for this change is so that we can eventually use a
separate `attoparsec`-based lexing step to greatly increase parsing speed since
the `trifecta`/`parsers` API doesn't allow tokens other than `Char`.
The secondary motivation for this is that `megaparsec` is a smaller dependency
that is more actively maintained.
This commit introduces dhalli, a fairly minimal Dhall REPL that supports:
* Evalution of Dhall expressions along with import resolution
* Type inspection of abritrary expressions
* Syntax highlighting and pretty printing for output
* Persistent bindings with :let
* Expression lookup with an implicit "it" binding
Fixes https://github.com/dhall-lang/dhall-lang/issues/86
This change has two benefits:
* Users of the Haskell API can now marshal Dhall values of type `Double` into
Haskell values of type `Scientific`
* The `dhall` executable no longer loses precision when dealing with
values that have a large exponent (see the newly added test)
Related to #244
This updates Dhall's syntax tree to use an insert-ordered hashmap to store
record fields and union alternatives. This in turn implies that they will be
formatted in the same order that they were originally parsed.
This is a breaking change to the API due to changing the type of map used in the
syntax tree.
Related to https://github.com/fpco/stackage/issues/3238
The immediate motivation of this change is to fix the upper bound issue
linked above. However, since we don't need the full `lens` dependency
this uses the much smaller and more stable `lens-family-core` library. Besides
reducing the footprint of the `dhall` executable this should hopefully also
reduce the number times we need to update the upper bound.
Related to #162
You can now add `sha256:XXX...XXX` after any import to verify that the import
has the expected hash. This allows you to purify import code and protect the
code against malicious modifications
This is analogous to an IPFS-style import except that the hash is verified
directly by the interpreter instead of trusting that the IPFS URL has not been
compromised
Fixes https://github.com/dhall-lang/dhall-lang/issues/8
This takes a Dhall expression on standard input and outputs the same
expression to standard output except pretty-printed in a standard format
This replaces all uses of `NeatInterpolation` with either multi-line
strings or `unlines`. This allows Dhall to be compiled without using
Template Haskell, which in turn enables cross-compilation
Users can now supply additional headers for URL imports using the new `using`
keyword, like this:
```haskell
http://example.com using ./headers
```
... where `./headers` must be a value of type:
```haskell
{ header : Text, value : Text }
```
The argument to `using` must be an import (such as a file, URL, or env import)
and cannot be an inline Dhall expression. There are two reasons why:
* The header expression is resolved, type-checked, and normalized in a separate
phase preceding the import of the corresponding URL so it does not have access
to bound variables in scop
* This restriction greatly simplifies the implementation
Also, headers are automatically forwarded to relative imports, so if you import a
URL like this:
```haskell
http://example.com using ./headers
```
... and that serves a file like:
```haskell
./foo
```
... then Dhall will import `http://example.com/foo` using the same `./headers`.
