Here is one case where Dhall could give a better error message
let def2 = {type={foo:Integer,bar:Bool,baz:Text},default={foo=+0,baz="kissa"}} in def2::{bar=True}
The above gives Error: Missing record field. Since :: is a builtin it could actually say what was missing.
Thanks for the report! I agree that the error message should report the field name.
Here's a smaller test case:
⊢ {=}.x
Error: Missing record field
1│ {=}.x
(stdin):1:1
Cool! Thanks. The original message ruined half an hour of my work.
But, I think it still could be improved by giving specific error message on record completion, instead of 'missing record field'. Also, several of short error messages also have arguments that could be shown.
Can I try to improve these if I find the time for it?
@aleator: Yeah, of course! 🙂
Just a quick check. I did some work on these, but I'm having trouble actually testing my changes, since the parser has gone really fuzzy on me:
echo "{foo:Integer}" |stack exec dhall
dhall:
Error: Invalid input
(stdin):1:6:
|
1 | {foo:Integer}
| ^^
unexpected "In"
expecting whitespace
Did I compile this somehow wrong or am I basing my work on the wrong branch?
@aleator {foo:Integer} isn't actually valid Dhall. The parser recently became stricter in its whitespace requirements, so you now have to add some whitespace after the :.
Hi, thanks, & sorry for being dense, but how do you write record completions nowadays?
Error: Invalid input
(stdin):1:58:
|
1 | {Type = {x : Integer, y : Bool}, default = {y = True}} :: {x = 5}
| ^^
unexpected ": "
expecting whitespace
There's no whitespace surrounding the complete-operator :::
⊢ {Type = {x : Integer, y : Bool}, default = {y = True}}::{x = +5}
{ x = +5, y = True }
You can find all the parsing rules (which the Haskell implementation adheres to quite closely now) in https://github.com/dhall-lang/dhall-lang/blob/master/standard/dhall.abnf.
Oh. I did check those but I had so strong notion that :: would be like other operators that I didn't pay enough attention
@aleator: Maybe we should allow spaces around it? I don't actually remember why we don't permit them and it might just be an oversight on our part.
I'm admittedly only a single data point, but it did confuse me by simultaneously requiring spaces around other operators and disallowing them here. Might be better to allow/require spaces
I would go toward whatever other languages are generally doing in such situation to minimize the effect of surprise. I would then try to be consistent (at first sight it is a bit surprising that in one situation you need spaces foo:Integer but here you need no space).
This kind of errors are so rare in other programming languages that you usually don't think about spaces that much as a programmer. Still I believe it can be useful to enforce rules (for instance I am not so sure it has been such a great idea to allow the haskell composition operator (.) to be used without any space).
Anyhow just want to say that this kind of "space" errors can have a dramatic impacts on new users. Would love any improvement on the matter ;-)
@PierreR: There's a specific reason we require a space in foo:Integer, which is so that env:FOO is not mistakenly parsed as a type annotation. However, that's an orthogonal issue; I can still add support for permitting spaces around the record completion operator
Fix is up here: https://github.com/dhall-lang/dhall-lang/pull/820
Most helpful comment
@aleator: Maybe we should allow spaces around it? I don't actually remember why we don't permit them and it might just be an oversight on our part.