-
Notifications
You must be signed in to change notification settings - Fork 214
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
with
expressions regressed
#2597
Comments
Interesting. Let me check my Scala implementation, as it passes all standard tests and implements the latest Dhall standard fully as documented. |
Yes, my Scala implementation fails both expressions. The error appears to be already in the Dhall standard in the typing judgments for this expression. Let me get the details.
This means: This appears to be wrong. At least, this does not in any way take into account the record access If this typechecking rule is implemented exactly as written in the standard, both of the examples will be not well-typed: (Some { x = 1 }) with ?.x = 2 -- Typechecking will set `T = { x : Natural}` and `v = 2`, but `2` is not of type `T`.
(Some { x = 1 }) with ?.x = "hello" -- Typechecking will set `T = { x : Natural}` and `v = "hello"`, but `"hello"` is not of type `T`. My Scala implementation reports these errors directly as:
The error is that |
Interesting. Why the restriction ? Why wasn't a rule like the following adopted ?
Edit: |
The intent was to prevent changing the types of values inside I don't really know the motivation; why is it allowed to do But that was the change. A Some { x = { y = 1 }} with ?.x.y = 2 -- Evaluates to Some { x = { y = 2 } }
Some { x = { y = 1 }} with ?.x = 0 -- Type error, it is not allowed to replace { y : Natural} with another type That's how I understand the intent behind this change. If this understanding is correct, then the current rule is wrong. It should have been something like this:
|
I'm just linking the PR that introduced this for reference: dhall-lang/dhall-lang#1254. |
I have looked through the discussions in there, and I don't see any real motivation for prohibiting the type change. The use case was that you need access to record fields under The usual Is there a reason to allow I would suggest that we revise the standard and fix the implementations so that users are allowed to change the type of values under |
* add failing tests * reformat * add more tests * fix the `with` regression as in dhall-lang/dhall-haskell#2597 * fix regression
what type |
Good point. Maybe that was the motivation for prohibiting the type change that would be happening for There are quite a few restrictions that come from the assumption that evaluation may not use any type information. This restriction is an example. Another example is that we cannot simplify |
Yeah, the reason the type is not supposed to change is so that evaluation doesn't need to infer the type. However, it is still weird that
|
@Gabriella439 Yes, I believe it is a specification bug that will produce the wrong behavior if implemented literally according to specification. I described that in a previous comment in this PR. I already fixed this in my Scala implementation. I can try to fix it when I have time (but this won't be soon, I am moving to a new apartment). |
With dhall 1.41.2, it used to be possible to do the following:
With dhall 1.42.1, a restriction was added forbidding a
with
expression from changing the type of an optional (it is a breaking change that was not announced in the changelog). This restriction is buggy and both the above expressions fail to evaluate with:The text was updated successfully, but these errors were encountered: