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

Dot notation with typeclass instances issue #1851

Closed
lecopivo opened this issue Nov 18, 2022 · 0 comments
Closed

Dot notation with typeclass instances issue #1851

lecopivo opened this issue Nov 18, 2022 · 0 comments

Comments

@lecopivo
Copy link

There seems to be an issue when using dot notation with type class instances.

mwe:

class Approx {α : Type} (a : α) (X : Type) : Type where
  val : X

variable {α β X Y : Type} {f' : α → β} {x' : α} [f : Approx f' (X → Y)] [x : Approx x' X]

-- fails
#check f.val x.val

-- works
#check let f'' := f.val
       let x'' := x.val
       f'' x''

The f.val x.val fails with

application type mismatch
  @Approx.val X (Approx.val x') ?m.70 f
argument
  f
has type
  Approx f' (X → Y) : Type
but is expected to have type
  Approx (Approx.val x') ?m.70 : Type

I would expect f.val x.val to typecheck

Tested on Lean (version 4.0.0-nightly-2022-11-18, commit 7529e86, Release)

digama0 pushed a commit to digama0/lean4 that referenced this issue Nov 30, 2022
github-merge-queue bot pushed a commit that referenced this issue Sep 27, 2024
Recall that currently named arguments suppress all explicit parameters
that are dependencies. This PR limits this feature to only apply to true
structure projections, except in the case where it is triggered when
there are no more positional arguments. This preserves the primary
reason for generalizing this feature (issue #1851), while removing the
generalized feature, which has led to numerous confusions (issue #1867).
This also fixes a bug pointed out [on
Zulip](https://leanprover.zulipchat.com/#narrow/stream/270676-lean4/topic/.40foo.20.28A.20.3A.3D.20bar.29.20_.20_/near/468564862)
where in `@` mode, instance implicit parameter dependencies to named
arguments would be suppressed unless the next positional argument was
`_`.

More detail:
* The `NamedArg` structure now has a `suppressDeps : Bool` field. It is
set to `true` for the `self` argument in structure projections. If there
is such a `NamedArg`, explicit parameters that are dependencies to the
named argument are turned into implicit arguments. The consequence is
that *all* structure projections are treated as if their type parameters
are implicit, even for class projections. This flag is *not* used for
generalized field notation.
* We preserve the suppression feature when there are no positional
arguments remaining. This feature pre-dates the fix to issue #1851, and
it is useful when combining named arguments and the eta expansion
feature, since dependencies of named arguments cannot be turned into eta
arguments. Plus, there are examples of the form `rw [lem (h := foo)]`
where `lem` has explicit arguments that `h` depends on.
* For instance implicit parameters in explicit mode, now `_` arguments
register terminfo and are hoverable.
* Now `..` is respected in explicit mode.

This implements RFC #5397. The `suppressDeps` flag suggests a future
possibility of a named argument syntax that can suppress dependencies.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant