Bug in type inference #2170
Comments
|
Thanks for reporting this! To set expectations:
Finally, please be patient with the core team. They are trying their best with limited resources. |
|
Can you explain in more detail why you think r1 and r2 should have
identical types? I do see a difference between them in that in r1, the
two calls to `sum` will have different resolved types, whereas in r2, both
calls to `sum` must necessarily have the same concrete type.
…On Wed, Feb 3, 2021 at 12:59 AM github-actions[bot] < ***@***.***> wrote:
Thanks for reporting this! To set expectations:
- Issues are reviewed in batches
<https://github.com/elm/expectations/blob/master/batching.md>, so it
can take some time to get a response.
- Ask questions a community forum <https://elm-lang.org/community>.
You will get an answer quicker that way!
- If you experience something similar, open a new issue. We like
duplicates
<https://github.com/elm/expectations/blob/master/duplicates.md>.
Finally, please be patient with the core team. They are trying their best
with limited resources.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2170 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAAJRUZ7AQR3DUCTSLM4T3S5EF63ANCNFSM4XAOPKPA>
.
|
|
Sure, from the which means that equals to Where do you see the difference? |
|
In the fully written-out version, each instance of `step` (or in the
original example, `sum`) can resolve to a different concrete type, but the
use of foldl forces all the instances to have the same concrete type.
You can see this when you add type annotations:
```
sum1 :
P.Parser (Int -> Int -> Int) (Int -> Int)
-> P.Parser (Int -> Int) Int
-> P.Parser (Int -> Int) Int
sum1 p1 p2 =
P.map ( ) (p1 </> p2)
sum2 :
P.Parser (Int -> Int -> Int) (Int -> Int)
-> P.Parser (Int -> Int) Int
-> P.Parser (Int -> a) a
sum2 p1 p2 =
P.map ( ) (p1 </> p2)
t1 : P.Parser (Int -> a) a
t1 =
P.int
|> sum1 P.int
|> sum1 P.int
|> sum2 P.int
t2 : P.Parser (Int -> a) a
t2 =
[ P.int, P.int, P.int ]
|> List.foldl sum1 P.int
|> P.map identity
```
Note that in `t1` (similar to your original `r1`), the final call to `sum2`
cannot be replaced with `sum1`. The final call does indeed need to have a
different type to match the `Parser (Int -> a) a` annotation that is given,
which also explains the need for `P.map identity` in `t2` (because the
argument to foldl will always be solved to have `sum1`'s type, and thus the
final call to it cannot leave `a` free).
…On Wed, Feb 3, 2021 at 2:25 AM Andrey Koppel ***@***.***> wrote:
Sure, from the List module docs
So `foldl step state [1,2,3]` is like saying:
state
|> step 1
|> step 2
|> step 3
which means that
[ P.int, P.int ]
|> List.foldl sum P.int
equals to
P.int
|> sum P.int
|> sum P.int
Where do you see the difference?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2170 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAAJRX2FAGSGI6JGH3OIZTS5EQB3ANCNFSM4XAOPKPA>
.
|
|
If I understand correctly, this type error message is correctly identifying that the type of |
|
I do understand that under the hood It does want This is valid. |
|
Or a more close example This is not valid. |
|
I think the original case should error. If you think there are cases here that should not error, please open an issue about those specific SSCCEs. I think all the cases mentioned here are working alright though. For example: It seems like the root issue is just that it's freaky how the types work with the URL parsers. |
|
Yes, indeed it’s about Url.Parser specifics. So no issue here. |
Quick Summary:
Seems like there is a bug in type inference.
r1andr2should have identical types.SSCCE
Additional Details
The compiler throws an error for
r2.I found a fix for this as well. Mapping with
identityfunction resolves the issue.The text was updated successfully, but these errors were encountered: