dhall-lang / dhall-json Goto Github PK

View Code? Open in Web Editor NEW

65.0 9.0 6.0 101 KB

This repository has moved to https://github.com/dhall-lang/dhall-haskell/tree/master/dhall-json

License: BSD 3-Clause "New" or "Revised" License

Haskell 68.98% Nix 31.02%

dhall json yaml configuration-language

dhall-json's Introduction

`dhall-json 1.2.4`

This repository has moved to:

https://github.com/dhall-lang/dhall-haskell/tree/master/dhall-json

This dhall-json package provides a Dhall to JSON compiler and a Dhall to YAML compiler. The reason this package is called dhall-json is that the Haskell yaml library uses the same data structure as Haskell's aeson library for JSON

Quick start

If you have Nix installed then you can build and run this package using:

$ nix-build -A dhall-json release.nix
$ result/bin/dhall-to-json <<< "{ foo = 1, bar = True }"
{"foo":1,"bar":true}
$ result/bin/dhall-to-json <<< "List/head Integer ([] : List Integer)"
null
$ result/bin/dhall-to-yaml <<< "{ foo = [1, 2, 3] : List Integer, bar = { baz = True } }"
foo:
- 1
- 2
- 3
bar:
  baz: true

Development status

I don't expect this library to change unless:

... the Dhall language changes, which is possible but not very likely
... there are bugs, which is unlikely given how simple the implementation is

License (BSD 3-clause)

Copyright (c) 2017 Gabriel Gonzalez
All rights reserved.

Redistribution and use in source and binary forms, with or without modification,
are permitted provided that the following conditions are met:
    * Redistributions of source code must retain the above copyright notice,
      this list of conditions and the following disclaimer.
    * Redistributions in binary form must reproduce the above copyright notice,
      this list of conditions and the following disclaimer in the documentation
      and/or other materials provided with the distribution.
    * Neither the name of Gabriel Gonzalez nor the names of other contributors
      may be used to endorse or promote products derived from this software
      without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR
ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

dhall-json's People

Contributors

Stargazers

Watchers

Forkers

joneshf profpatsch deepfire domenkozar f-f justinwoo

dhall-json's Issues

Test suite does not compile with aeson-1.2.4.0 (Stackage LTS 11.22)

[1 of 1] Compiling Main             ( tasty/Main.hs, dist-ghc/build/tasty/tasty-tmp/Main.o )

tasty/Main.hs:52:19: error:
    Not in scope: ‘Data.Aeson.eitherDecodeFileStrict’
    Perhaps you meant one of these:
      ‘Data.Aeson.eitherDecodeStrict’ (imported from Data.Aeson),
      ‘Data.Aeson.eitherDecodeStrict'’ (imported from Data.Aeson)
    Module ‘Data.Aeson’ does not export ‘eitherDecodeFileStrict’.

eitherDecodeFileStrict was added in aeson-1.3.0.0

Interest in json-to-dhall and yaml-to-dhall?

We have programs for taking Dhall and making JSON. Is there any interest in a program that takes JSON and makes Dhall? I often find myself reaching for jq as an alternative, but its UX isn't the best for me. Similarly for yq.

Thoughts?

OOM killed when using headers with file with relative import

Reproduce:

Download https://gist.github.com/reactormonk/a8192fe784608f1f7515d5583c448095

dhall-to-yaml < local.dhall

Enjoy OOM!

Record output should have sorted keys

Right now the records output will output whatever order the record was constructed. There should probably be some aeson-pretty options for this?

Nobody should use the observed insertion order anyways

Labels of records should be quoted in YAML

When translating a record to YAML, the labels should always be quoted.

Otherwise you can run into bugs like this:

$ echo '{ true = "this is true"} ' | dhall-to-yaml
true: this is true

which is wrong because true is now an actual boolean. Intead it should quote the label:

"true": this is true

Template Haskell build error (1.0.8, ghcjs)

Reproduce on current nixpkgs master (32169472017ac91e763cc7ff97f232c99d4db663):
nix-build -A haskell.packages.ghjcsHEAD.dhall-json ./nixpkgs

Works with normal ghc nix-build -A haskellPackages.dhall-json ./nixpkgs.

Building dhall-json-1.0.8...
Preprocessing library dhall-json-1.0.8...
[1 of 1] Compiling Dhall.JSON       ( src/Dhall/JSON.hs, dist/build/Dhall/JSON.js_o )
Linking Template Haskell ()
runNodeInteractive
Linking Template Haskell (ThRunner1)

src/Dhall/JSON.hs:132:26: error:
    • The exact Name ‘txt_aJc’ is not in scope
        Probable cause: you used a unique Template Haskell name (NameU), 
        perhaps via newName, but did not bind it
        If that's it, then -ddump-splices might be useful
    • In the quasi-quotation:
        [NeatInterpolation.text|
$_ERROR: Cannot translate to JSON

Explanation: Only primitive values, records, unions, ❰List❱s, and ❰Optional❱
values can be translated from Dhall to JSON

The following Dhall expression could not be translated to JSON:

↳ $txt
|]
builder for ‘/nix/store/kpi9zsbnbwsqyrd5k529isaf59iwiiv7-dhall-json-1.0.8.drv’ failed with exit code 1

Support yaml separators

Use-case: I have a List {...}, and I'd like to map over that list and output several yaml objects (to the same file with separators, or to different files, not really relevant).
There is some ways to solve this issue, e.g.:

output the values to bash var separated by newlines, run a for loop to run dhall-to-yaml either piping to the same file after piping there a separator, or to different files
write a haskell program that reads the list, converts each value to yaml, and outputs to file(s)

It would be nice if dhall-to-yaml had a flag (--separators?) such that if the top object is a List, every element would be converted to yaml, and there would be a separator in between.

Something like:

$ dhall-to-yaml --separators <<< "[1, 2, 3]"
1
---
2
---
3

A value that can be either a primitive or a record

Is it possible to create a Dhall file that will generate the following stack.yaml?

Each item in packages could either be a primitive value (string) or a record.

packages:
- '.'
- location:
    git: [email protected]:Gabriel439/Haskell-Dhall-Library.git
    commit: aeb7d165251a0612538e0ca8f84d60b5aaac6c8d
  subdirs: []
  extra-dep: true

Or written this way, the problem shifts to location, which is either a primitive value or a record.

packages:
- location: '.'
- location:
    git: [email protected]:Gabriel439/Haskell-Dhall-Library.git
    commit: aeb7d165251a0612538e0ca8f84d60b5aaac6c8d
  subdirs: []
  extra-dep: true

My tendency is to reach for Dhall's union type, but that is not a currently supported translation:

Explanation: Only primitive values, records, ❰List❱s, and ❰Optional❱ values can be translated from Dhall to JSON

It might be helpful to allow for unions to translate to overlapping types for situations like this.

Using unions in this way is more similar to TypeScript's union type, since the explicit tag would get lost in translation.

list of unions not converted to maps

I'm writing some GoCD pipeline configs in dhall and ran into the following issue. Given this dhall file:

let MaterialSource =
  { mapKey : Text
  , mapValue :
    { git : Text
    , branch : Text
    }
  }
in let MaterialPipeline =
  { mapKey : Text
  , mapValue :
    { pipeline : Text
    , stage : Text
    }
  }
in let Material = < Source : MaterialSource | Pipeline : MaterialPipeline >
in let unionMaterial = constructors Material
in let Materials = List Material
in let materials : Materials =
  [ unionMaterial.Source
    { mapKey = "someRepo"
    , mapValue =
      { git = "www.example.com/user/repo.git"
      , branch = "master"
      }
    }
  , unionMaterial.Pipeline
    { mapKey = "somePipeline"
    , mapValue =
      { pipeline = "someOtherPipeline"
      , stage = "build"
      }
    }
  ]
in materials

I get this output:

- mapKey: someRepo
  mapValue:
    branch: master
    git: www.example.com/user/repo.git
- mapKey: somePipeline
  mapValue:
    stage: build
    pipeline: someOtherPipeline

whereas I would have expected:

someRepo:
    branch: master
    git: www.example.com/user/repo.git
somePipeline:
    stage: build
    pipeline: someOtherPipeline

I'm new to dhall so it's likely i'm doing something wrong, any help would be appreciated.

Slow compile times

In attempting to fully type the interface to Terraform's Datadog provider, I ended up with a 1200 line dhall file full of types and functions.

I have not started to optimize, as I'm still trying to wrap up the last few features I want to express in this PoC, though it's not immediately apparent (other than "have less code to compile!") how to optimize this.

I'm expecting that many different graph types will be required by many different consumers, so I'm reticent to break up the object structure, though that's definitely low hanging fruit (at the expense of making my consumers copy/paste 9 different imports into every file they write).

As the project has gotten to the point where it takes 30 seconds to compile at minimum, up to 1.5m for particularly large dashboards, I figure this is the time to start this discussion. I see some active work in dhall-lang/dhall-haskell#108, is the answer here just "wait for speed improvements"?

1.1.0 build failure

Building library for dhall-json-1.1.0..
[1 of 1] Compiling Dhall.JSON       ( src/Dhall/JSON.hs, dist/dist-sandbox-a87d045f/build/Dhall/JSON.o )

src/Dhall/JSON.hs:212:45: error:
    • Couldn't match type ‘[Char]’
                     with ‘trifecta-1.7.1.1:Text.Trifecta.Delta.Delta’
      Expected type: trifecta-1.7.1.1:Text.Trifecta.Delta.Delta
        Actual type: String
    • In the first argument of ‘Dhall.Parser.exprFromText’, namely
        ‘(Data.Text.unpack name)’
      In the expression:
        Dhall.Parser.exprFromText
          (Data.Text.unpack name) (Data.Text.Lazy.fromStrict code)
      In a stmt of a 'do' block:
        expr <- case
                    Dhall.Parser.exprFromText
                      (Data.Text.unpack name) (Data.Text.Lazy.fromStrict code)
                of
                  Left err -> throwIO err
                  Right expr -> return expr
    |
212 |     expr <- case Dhall.Parser.exprFromText (Data.Text.unpack name) (Data.Text.Lazy.fromStrict code) of
    |                                             ^^^^^^^^^^^^^^^^^^^^^
cabal: Leaving directory '.'
cabal: Error: some packages failed to install:
dhall-json-1.1.0-BY8sJc7rqyqBzpC2NNoGuA failed during the building phase. The
exception was:
ExitFailure 1

https://jenkins.brew.sh/job/Homebrew%20Core%20Pull%20Requests/23158/version=el_capitan/testReport/junit/brew-test-bot/el_capitan/install_dhall_json/

Convert some association lists to homogeneous maps?

The context for this is: dhall-lang/dhall-lang#136

Many JSON schemas expect homogeneous maps (i.e. the JSON equivalent of Haskell's Data.Map.Map), such as in the following contrived JSON configuration:

{
  "users": {
    "john": {
      "admin": false
    },
    "mary": {
      "admin": true
    },
    "alice": {
      "admin": false
    }
  }
}

... where you would not necessarily know the set of users statically in advance.

The idiomatic Dhall type corresponding to the above JSON configuration would be something like:

{ users : List { key : Text, value : { admin : Bool } } }

The question here is whether or not dhall-to-json and dhall-to-yaml should support automatically converting association lists with a reserved field name to homogeneous maps.

The easiest way to explain this is to show the following example encoding of the above JSON configuration:

{ users =
    [ { key = "john", value = { admin = False } }
    , { key = "mary", value = { admin = True } }
    , { key = "alice", value = { admin = False } }
    ]
}

Some variations on this proposal:

Make this behavior opt-in (i.e. off by default) and guard it behind a command line flag
Don't implement this in dhall-to-json/dhall-to-yaml and instead implement this in more specific integrations (like dhall-to-terraform)
Don't reserve the field named value; any field name is fine as long as the other field is named key
Reserve different field names
Allow the user to specify which field name(s) to reserve for this transformation on the command line
Don't do this at all :)

nested association lists were not converted to maps

dhall-to-json doesn't work when we supply an association list where the mapValue itself is an association list. For example

[ { mapKey = "somekey", mapValue = [ { mapKey = "\$gt", mapValue = 100 } ] } ]

was converted to

{
  "somekey": [
    {
      "mapKey": "$gt",
      "mapValue": 100
    }
  ]
}

but I guess the expected output should be:

{
  "somekey": {
    "$gt": 100
  }
}

Is it possible to make the conversion recursive so that it would generate the expected result? I am new to dhall (and Haskell) so please correct me if I am wrong.

Yaml file validation

It seems to me I could use the library to do yaml file validation.

Is it something that might be added in the future ?

Better handling of JSON sums

We have a bunch of Packer files at work that have a bunch of redundancy between them, so I thought this was a good use case for Dhall. It turned out to be more trouble than it's worth though. There's a provisioners field that contains a list of instructions for provisioning VMs using various tools. E.g.:

{
  // other stuff
  "provisioners": [
    {
      "type": "shell",
      "inline": ["echo foo"]
    },
    {
      "type": "file",
      "source": "app.tar.gz",
      "destination": "/tmp/app.tar.gz"
    }
  ]
}

There are lots of kinds of provisioners, distinguished by the type field. The natural Dhall encoding is something like < File : { source: Text, dest: Text} | Shell : List Text>, but if I want to convert that to JSON that Packer will accept, the output type has to be {type: Text, source: Optional Text, destination: Optional Text, inline: Optional Text}. That gets worse as I add support for more provisioners. Writing the provisioner to JSON function is ugly too:

   let provisionerEmpty = {
         source = [] : Optional Text,
         destination = [] : Optional Text,
         inline = [] : Optional (List Text)}
in let provisioner_to_json = \(p: Provisioner) ->
         merge
         {File = \(ps: {source: Text, dest: Text}) -> provisionerEmpty // {type = "file", source = [ps.source] : Optional Text, destination = [ps.dest] : Optional Text},
          Shell = \(lines: List Text) -> provisionerEmpty // {type = "shell", inline = [lines] : Optional (List Text)}
         }
         p in ...

It'd be great if there was a nice way of generating JSON sum types.

Ambiguous Unions in JSON output?

I could be wrong, but are the JSON representation of unions ambiguous?

Example:

~/temp/dhall-examples
$ cat type3.dhall
[ < Left = +1 | Right : Bool | Other : Natural >
, < Other = +3 | Right : Bool | Left : Natural >
] : List < Left : Natural | Right : Bool | Other : Natural >

~/temp/dhall-examples
$ dhall-to-json < type3.dhall
[1,3]

Date and time types and syntax

Would it be possible to add date and time of day, and date-time as first class values with their own literals syntax? We would probably want to think about time zones, while we are at it?

I am thinking of something like 2018-01-31 or so. The use case is that we are evaluating dhall for use as a configuration langue to specify when to schedule jobs. (Think like a cron on steroids.) Ability to specify time differences would also be handy.

Create the .travis.yml file with a dhall definition

I'm looking into dhall to build configuration files for gitlab and maybe kubernetes, so was looking into the repository a bit, and I was wondering if it would be a nice showcase/example to have your .travis file build with dhall?

Valid Dhall not parsed by dhall-to-{json,yaml}

Apologies if this has already been fixed, I'm having some issues getting the most recent versions compiled (tool chain issues on my end).

% dhall <<< '{foo="bar",}'
{ foo : Text }

{ foo = "bar" }
% src/Haskell-Dhall-JSON-Library/result/bin/dhall-to-yaml <<< '{foo="bar",}'

(stdin):1:1: error: expected: "[",
    "\8704", "\955", "\\", "forall",
    "if", "let", "merge"
{foo="bar",}
^
 % src/Haskell-Dhall-JSON-Library/result/bin/dhall-to-yaml <<< '{foo="bar"}'
foo: bar

Notice the trailing ,. While {"foo": "bar",} is not valid JSON, {foo = "bar",} is valid dhall and equivalent to {foo="bar"}, so I wouldn't expect the two to produce different JSON/Yaml, let alone have one be considered an error.

Fails to compile with the latest `dhall-haskell`

dhall-json/src/Dhall/JSON.hs

Line 173 in d6adaa2

Dhall.Core.TextLit (Dhall.Core.Chunks [] a) -> do

This line yields an error, when compiled with the tip of dhall-haskell's master:

src/Dhall/JSON.hs:173:29: error:
    Not in scope: data constructor ‘Dhall.Core.Chunks’
    Perhaps you meant ‘Dhall.Core.Const’ (imported from Dhall.Core)
    Module ‘Dhall.Core’ does not export ‘Chunks’.
note: keeping build directory ‘/tmp/nix-build-dhall-json-1.0.9.drv-14’

A bit of an expression problem

I'm trying to write a convenient eDSL in dhall to generate a particular yaml structure from a clean spec language.
Say I want to generate the following yaml:

    steps:
    - checkout
    - run:
        command: mycommand
        working_directory: mydir

the list is not homogeneous so looks like I have to resort to the following rep before converting to the yaml rep.

let RunStep = { name              : Optional Text
, working_directory : Optional Text
, command           : Text
}
in let Step = < Checkout : Text | Run : { run : RunStep } >

and have helpers to construct the values

let checkout = < Checkout = "checkout" | Run : { run : RunStep } >

in let defRun = \(cmd : Text) ->
  let step =  { name              = None Text
              , working_directory = None Text
              , command           = cmd
              } : RunStep
  in < Checkout : Text | Run = { run = step } >

my problem is that I cannot figure out a convenient way to modify the default run step template.
I would love to be able to do something like

let myRunStep = defRun // { working_directory = "mydir" }

or something similar but cannot figure out how.
Are there any good patterns that can help me?

trifecta bump needed

With GHC 8.0.2 and Cabal 2.0.0.0 the build fails in a Cabal sandbox with the error

Building trifecta-1.6.2.1...
Preprocessing library trifecta-1.6.2.1...
[ 1 of 13] Compiling Text.Trifecta.Util.IntervalMap ( src/Text/Trifecta/Util/IntervalMap.hs, dist/dist-sandbox-f96742a3/build/Text/Trifecta/Util/IntervalMap.o )
[ 2 of 13] Compiling Text.Trifecta.Util.Combinators ( src/Text/Trifecta/Util/Combinators.hs, dist/dist-sandbox-f96742a3/build/Text/Trifecta/Util/Combinators.o )
[ 3 of 13] Compiling Text.Trifecta.Util.Array ( src/Text/Trifecta/Util/Array.hs, dist/dist-sandbox-f96742a3/build/Text/Trifecta/Util/Array.o )
[ 4 of 13] Compiling Text.Trifecta.Instances ( src/Text/Trifecta/Instances.hs, dist/dist-sandbox-f96742a3/build/Text/Trifecta/Instances.o )

src/Text/Trifecta/Instances.hs:18:10: error:
    Duplicate instance declarations:
      instance Data.Semigroup Doc
        -- Defined at src/Text/Trifecta/Instances.hs:18:10
      instance [safe] Data.Semigroup Doc
        -- Defined in ‘Text.PrettyPrint.ANSI.Leijen.Internal’
Failed to install trifecta-1.6.2.1
cabal: Error: some packages failed to install:
dhall-1.5.1-AIPTNjvj7BN5FxlhYpbUg7 depends on dhall-1.5.1 which failed to
install.
trifecta-1.6.2.1-2vPOScXwOhmFuR3MyAzULj failed during the building phase. The
exception was:
ExitFailure 1

Full build log https://gist.github.com/ilovezfs/4f84b5165dd7538d34eb147bf805e668

Binary Releases?

I'd love to be able to use dhall-to-json and dhall-to-yaml in places where the Haskell or nix toolchain is not set up. We could build binaries on travis for OSX and linux, then uploading them through GitHub Releases. It would allow people to use these binaries whether or not they have Haskell or nix setup (or are restricted from that for whatever reason).

@Gabriel439 Would you be interested in a PR for that?

Sort in record not supported ?

Dhall 1.18 introduced kind-polymorphism thanks to a Sort constant above Kind.

Generating yaml|json from a value annotated by fixing a Sort contained by a record throws an error

test.dhall

    let A = { X = { a : Text }, Y = λ(K : Type) → { a : K } }

in  { a = 1 } : A.Y Natural

dhall <<< ./test.dhall

{ a = 1 }

dhall-to-yaml <<< ./test.dhall

Error: Invalid field type

{ X = { a : Text }, Y = λ(K : Type) → { a : K } }

Extracting Y from A make the above command working.
Am I missing something or this behavior was not expected ?

optparse-generic bump needed

http://hackage.haskell.org/package/optparse-generic-1.1.5/optparse-generic.cabal
requires time >= 1.5 && < 1.7

http://hackage.haskell.org/package/optparse-generic/optparse-generic.cabal
requires time >= 1.5 && < 1.9

GHC 8.2.1 ships with time-1.8.0.2.

Double newline in yaml

{ x = ''foo
bar
'' }

gives

$ dhall-to-yaml < bug.dhall 
x: ! 'foo

  bar

'

Heterogenous JSON array targets / JSON AST target?

While trying to encode to the following JSON structure I end up with the need to encode a JSON heterogenous array:

{"Fn::Select": [0, {"Fn::GetAZs": {"Ref": "AWS::Region"}}]}

This is part of the Cloudformation intrinsic function syntax. See the reference here: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-select.html

It asks for a 2 element array where the first item is a JSON number and the 2nd is a array of arbitrary JSON values.

Currently, and please correct me: There is no dhall value possible that dhall-json would generate this two element JSON array?

Assuming the above question indeed gets answered with: No. I see two options to move on:

Add another special case dhall-json detects on conversion to JSON
A more universal approach (described below).

Another approach

Context:

The JSON syntax allows to specify a lot of "odd" data structures. There may be target schemas that require explicit null values, or other structures we cannot easily find a dhall equivalent for. Adding special cases to dhall-json may be the wrong approach to handle them all. Also in many cases the special case may be "too special" to warrant another addition to dhall-json.

So what if dhall-json (at the dhall language level!) came with an implementation of a JSON AST? Types shipped with a dhall-json specific prelude the dhall-json Haskell implementation maps directly to aeson Value?

The nice benefit of this approach is that authors like me can keep their dhall values as compact as possible, not infecting them with JSON specific structure "early on" and only in the very last step can write some still dhall level conversion functions to that said AST.

I think this approach can likely eliminate the need to drop down to custom Haskell in many cases.

For now I'll go ahead and implement my own cloudformation specific special cases. Still I'd love to get critical feedback on this idea.

Does not build

getting following error when trying to stack install
(looks like it's missing None and Some from the newer Dhall.Core)

Preprocessing library for dhall-json-1.2.3..
Building library for dhall-json-1.2.3..
[1 of 1] Compiling Dhall.JSON       ( src/Dhall/JSON.hs, .stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build/Dhall/JSON.o )

/Users/ababkin/work/dhall-json/src/Dhall/JSON.hs:252:9: error:
    Not in scope: data constructor ‘Dhall.Core.Some’
    Perhaps you meant one of these:
      ‘Dhall.Core.Home’ (imported from Dhall.Core),
      ‘Dhall.Core.Note’ (imported from Dhall.Core),
      ‘Dhall.Core.Code’ (imported from Dhall.Core)
    Module ‘Dhall.Core’ does not export ‘Some’.
    |
252 |         Dhall.Core.Some a -> do
    |         ^^^^^^^^^^^^^^^

/Users/ababkin/work/dhall-json/src/Dhall/JSON.hs:255:24: error:
    Not in scope: data constructor ‘Dhall.Core.None’
    Perhaps you meant one of these:
      ‘Dhall.Core.Note’ (imported from Dhall.Core),
      ‘Dhall.Core.Home’ (imported from Dhall.Core),
      ‘Dhall.Core.Code’ (imported from Dhall.Core)
    Module ‘Dhall.Core’ does not export ‘None’.
    |
255 |         Dhall.Core.App Dhall.Core.None _ -> do
    |                        ^^^^^^^^^^^^^^^

/Users/ababkin/work/dhall-json/src/Dhall/JSON.hs:602:9: error:
    Not in scope: data constructor ‘Dhall.Core.Some’
    Perhaps you meant one of these:
      ‘Dhall.Core.Home’ (imported from Dhall.Core),
      ‘Dhall.Core.Note’ (imported from Dhall.Core),
      ‘Dhall.Core.Code’ (imported from Dhall.Core)
    Module ‘Dhall.Core’ does not export ‘Some’.
    |
602 |         Dhall.Core.Some a ->
    |         ^^^^^^^^^^^^^^^

/Users/ababkin/work/dhall-json/src/Dhall/JSON.hs:603:13: error:
    Not in scope: data constructor ‘Dhall.Core.Some’
    Perhaps you meant one of these:
      ‘Dhall.Core.Home’ (imported from Dhall.Core),
      ‘Dhall.Core.Note’ (imported from Dhall.Core),
      ‘Dhall.Core.Code’ (imported from Dhall.Core)
    Module ‘Dhall.Core’ does not export ‘Some’.
    |
603 |             Dhall.Core.Some a'
    |             ^^^^^^^^^^^^^^^

/Users/ababkin/work/dhall-json/src/Dhall/JSON.hs:607:9: error:
    Not in scope: data constructor ‘Dhall.Core.None’
    Perhaps you meant one of these:
      ‘Dhall.Core.Note’ (imported from Dhall.Core),
      ‘Dhall.Core.Home’ (imported from Dhall.Core),
      ‘Dhall.Core.Code’ (imported from Dhall.Core)
    Module ‘Dhall.Core’ does not export ‘None’.
    |
607 |         Dhall.Core.None ->
    |         ^^^^^^^^^^^^^^^

/Users/ababkin/work/dhall-json/src/Dhall/JSON.hs:608:13: error:
    Not in scope: data constructor ‘Dhall.Core.None’
    Perhaps you meant one of these:
      ‘Dhall.Core.Note’ (imported from Dhall.Core),
      ‘Dhall.Core.Home’ (imported from Dhall.Core),
      ‘Dhall.Core.Code’ (imported from Dhall.Core)
    Module ‘Dhall.Core’ does not export ‘None’.
    |
608 |             Dhall.Core.None
    |             ^^^^^^^^^^^^^^^

Completed 94 action(s).