Nadrieril

Oh wait no you're right, this merge only removes one layer but we want it to be recursive. I need to think about this more carefully. EDIT: I've opened https://github.com/dhall-lang/dhall-lang/issues/1028...

My opinion on this is that this would be extremely cool. Regarding type annotations, here is what I had in mind: importing without a type annotation should be ok, because...

I remember adding a unit test for this at some point. I'm not sure if either parse is more intuitive, I wouldn't mind rejecting both to force the user to...

There was a proposal for allowing hashes anywhere. That would fix the issue with `?`. It doesn't say anything about `using` though

Since we keep wanting better pattern-matching features, could we maybe drop the `merge` keyword entirely in favor of some real pattern-matching syntax? e.g. ``` let bar = match foo {...

Well, this is actually part of the design decisions of the language: every subexpression should have a single and easy-to-compute type. This is not unchangeable but runs quite deep in...

I don't know about hiccups: Dhall has some learning curve, but once you got it it's quite clear where you need those `Some`s and `None`s. However I do agree that...

Then indeed Dhall may not be what you're looking for. Alternatives I've heard about include the recently-released [Nickel](https://www.tweag.io/blog/2020-10-22-nickel-open-sourcing), [Starlark](https://github.com/bazelbuild/starlark) and [Jsonnet](https://jsonnet.org/).

I also find that the two notions of integrity checking and caching are too entangled in dhall and that this leads to confusion and inefficiencies. I have several issues with...

@Gabriel439 What use case do you have in mind for specifying that an import must be cached ? Also, if we were to find another mechanism than integrity checks for...