Open jllang opened 3 years ago
insL
and insR
?Here's the link: https://privatebin.net/?2b64c18c8da919bc#BPts1wpxjXVxaLyzqM9RdhP5Zwtp6E2AqhkxcainToFg
I haven't modified the signatures. My implementation for insR
is pretty much the mirror image of insL
. If I comment out everything about insR
, then these errors go away.
Hi John,
This kind of thing can happen sometimes as an odd consequence of local inference.
Suppose you have two "public" functions
foo :: Nat -> Nat foo x = incr x
bar :: Int -> Int bar x = incr x
both of which use a "private" helper function
incr :: Int -> Int incr x = 2 * x
If you OMIT a signature for incr
, then LH infers that INCR has the type
incr :: Nat -> Nat
as it is only called by foo
with Nat
inputs.
However, if you add the function bar
into the mix, then LH infers a
weaker type for incr,
incr :: Int -> Int
which is too weak to prove the type of foo
, thus triggering an error in
foo
.
As an example see this
http://goto.ucsd.edu:8090/index.html#?demo=permalink%2F1627321397_37616.hs
So: in your case, check if there is some common helper function who lacks a type signature?
Or can you send me the full code (in addition to insR) you’re running so I can see if it’s this or something else ?
Thanks!
On Mon, Jul 26, 2021 at 10:47 AM Ranjit Jhala @.***> wrote:
Hi John,
This kind of thing can happen sometimes as an odd consequence of local inference.
Suppose you have two "public" functions
foo :: Nat -> Nat foo x = incr x
bar :: Int -> Int bar x = incr x
both of which use a "private" helper function
incr :: Int -> Int incr x = 2 * x
If you OMIT a signature for
incr
, then LH infers that INCR has the typeincr :: Nat -> Nat
as it is only called by
foo
withNat
inputs.However, if you add the function
bar
into the mix, then LH infers a weaker type for incr,incr :: Int -> Int
which is too weak to prove the type of
foo
, thus triggering an error infoo
.As an example see this
http://goto.ucsd.edu:8090/index.html#?demo=permalink%2F1627321397_37616.hs
So: in your case, check if there is some common helper function who lacks a type signature?
I get errors when I try to define
insR
symmetrically to howinsL
has been defined above. However, these errors are aboutinsL
rather thaninsR
. How can it be? These are the errors I get:How can it be that modifying one function breaks another independent function?