Skip to content
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

[ fix #3448 ] Fix %search in constraint #3451

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

spcfox
Copy link
Contributor

@spcfox spcfox commented Dec 20, 2024

Description

Added parameters to constraint hints to fix #3448

Should this change go in the CHANGELOG?

  • If this is a fix, user-facing change, a compiler change, or a new paper
    implementation, I have updated CHANGELOG_NEXT.md (and potentially also
    CONTRIBUTORS.md).

= do let pNames = map fst params
let ity = apply (IVar fc iname) (map (IVar fc) pNames)
let fty = mkTy fc Implicit (map jname params) $
mkTy fc Explicit [(Nothing, top, ity)] con
ty_imp <- bindTypeNames fc [] (meths ++ vars) fty
Copy link
Contributor Author

@spcfox spcfox Dec 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do I need to add parameters?

ty_imp <- bindTypeNames fc [] (pNames ++ meths ++ vars) fty

like in mkIfaceData

con = MkImpTy vfc (NoFC conName) !(bindTypeNames ifc [] (pNames ++ map fst meths ++ vars) conty)

and in getMethDecl
ty_imp <- bindTypeNames EmptyFC [] (paramNames ++ mnames ++ vars) ty

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems to me that this might be necessary since I added parameters to fty, but I can't think of an example where this would have an impact

Comment on lines -18 to -41
Fld:76:1--81:38
76 | interface Show a => (num : Num a) => MyIface a where -- Some interface with
77 | constructor MkIface
78 | -- constraints
79 | data MyData : a -> Type -- and a data declaration.
80 | someFunc : a -> a -- Constraints are now elaborated as auto implicits (as one would expect)
81 | giveBack : {x : a} -> MyData x -> a -- (previously as explicit arguments of the interface

Warning: We are about to implicitly bind the following lowercase names.
You may be unintentionally shadowing the associated global definitions:
a is shadowing Main.R2.R2.a, Main.R1.R1.a

Fld:76:1--81:38
76 | interface Show a => (num : Num a) => MyIface a where -- Some interface with
77 | constructor MkIface
78 | -- constraints
79 | data MyData : a -> Type -- and a data declaration.
80 | someFunc : a -> a -- Constraints are now elaborated as auto implicits (as one would expect)
81 | giveBack : {x : a} -> MyData x -> a -- (previously as explicit arguments of the interface

Warning: We are about to implicitly bind the following lowercase names.
You may be unintentionally shadowing the associated global definitions:
a is shadowing Main.R2.R2.a, Main.R1.R1.a

Copy link
Contributor Author

@spcfox spcfox Dec 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like these warnings were occurring in hints for constraints. They disappeared after changes to getConstraintHint. I'm not sure if they are useful, but it seems odd

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if they are useful, but it seems odd

To me these warning look completely okay, since both interface definition and interface implementations seem to shadow the top-level as

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, but in the following code MyIface0, MyIface1 and MyIface2 produce 0, 1 and 2 warnings respectively. This means that one warning per constraint is generated. This is because they do not arise from the data the interface is elabored into, but from the constraint hint. This is strange

a : Type

interface MyIface0 a where
  f0 : a -> Type

interface Show a => MyIface1 a where
  f1 : a -> Type

interface Show a => (num : Num a) => MyIface2 a where
  f2 : a -> Type

Copy link
Contributor Author

@spcfox spcfox Dec 22, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A warning about shadowing is produced when a is an unbound implicit, but in the above examples a is explicitly bound

a : Type

-- Produce warning
interface Iface1 (x : a) where

-- No warning
interface Iface2 a (x : a) where

Previously, it was unbound at elaboration constraint hint

@spcfox spcfox changed the title [ fix #3448 ] Fix constraint search [ fix #3448 ] Fix %search in constraint Dec 20, 2024
@spcfox
Copy link
Contributor Author

spcfox commented Dec 20, 2024

%search still can't find implicitly bound parameters:

X : Type
data Y : X -> Type

failing "While processing constructor MkZ. Can't find an implementation for X"
  interface Y %search => Z (y : Y x) where
    constructor MkZ

interface Y x => Z (y : Y x) where
  constructor MkZ

0 getX : Z y => X
getX = %search

I expected that adding pNames would fix it, but no

@spcfox
Copy link
Contributor Author

spcfox commented Dec 20, 2024

Ok, it's not a problem with interfaces

X : Type
data Y : X -> Type

failing "While processing constructor MkZ. Can't find an implementation for X"
  interface Y %search => Z (y : Y x) where
    constructor MkZ

-- The interface is elaborated into such data
failing "While processing constructor MkZ. Can't find an implementation for X"
  data Z : Y x -> Type where
    MkZ : {y : Y x} -> Y %search => Z y

I created issue #3452 for this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

%search cannot find the parameter in the interface constraint
3 participants