Basile Henry

I actually think [`v21.0.0`](https://github.com/dhall-lang/dhall-lang/blob/master/CHANGELOG.md#v2100) of the standard adds this feature where a map of headers that can be specified via the `DHALL_HEADERS` environment variable. So maybe this is something we...

This is not ideal but you can do the function application in Dhall: ```rust fn run_dhall_fn(func: &str, input: u64) -> serde_dhall::Result { let input = serde_dhall::serialize(&input).to_string()?; serde_dhall::from_str(&format!("({}) {}", func, input)).parse()...

> My only suggestion is to make the strict behavior the default, with a flag to opt out and recover the old behavior Should the strict behaviour only be used...

I believe I have managed to convert all the existing source span based comment parsing to explicit comment parsing. There are lots of places that still need explicit comment parsing...

Thanks for the review! 😄 It looks like my latest changes to the comment rendering logic broke the idempotence tests. I will have another go at fixing this, maybe by...

It looks like the way I am rendering the `MultiComment`s (by merging them) is incompatible with some of the assumptions around how comments are kept after formatting in `dhall-docs`. I...

@Gabriel439 You're right, it might be nice to merge consecutive doc comments as well. I think the issue is merging doc comments with plain comments. That is probably unexpected behaviour...

Thanks! Cheers appreciated :smile: I will fix the remaining `dhall-docs` test failures ASAP so we can merge this soon. :crossed_fingers: Once this PR goes in, the main difference to the...

It is known behaviour. `dhall-haskell` currently only parses the comment at the top of the file and drops the rest. There have been some efforts towards parsing all comments in...

We could imagine a simpler sugar for defaults over lists. I don't think `Object::[ x, y, z ]` currently parses so it should be feasible to make it a sugar...