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

Ltac2 lacks proper abstract types (and related features) #18656

Open
rlepigre opened this issue Feb 10, 2024 · 2 comments · May be fixed by #18766
Open

Ltac2 lacks proper abstract types (and related features) #18656

rlepigre opened this issue Feb 10, 2024 · 2 comments · May be fixed by #18766
Labels
kind: feature New user-facing feature request or implementation. part: ltac2 Issues and PRs related to the (in development) Ltac2 tactic langauge.

Comments

@rlepigre
Copy link
Contributor

rlepigre commented Feb 10, 2024

I sometimes really miss the ability to hide the implementation details of an Ltac2 type.

Ideally, there would be an #[abstract] attribute that one could add to Ltac2 type to specify that the type is to be seen as abstract from any function not in the current module. For example:

Module Counter.
  #[abstract] Ltac2 Type t := int ref.
  Ltac2 create : unit -> t := fun () => Ref.ref 0.
  Ltac2 incr : t -> unit := Ref.incr.
  Ltac2 get : t -> int := Ref.get.
End Counter.

(* Fails with something like: [r] has type [Counter.t] but is expected to have type [int Ref.t]. *)
Fail Ltac2 incr_n : Counter.t -> int -> unit := fun r i =>
  Ref.set r (Int.add i (Ref.get r)).

A variation of that attribute could be #[private], forbidding one to construct values of the type outside of the module where it is defined, but still allowing matching.

How hard would these be to implement?

@rlepigre rlepigre added kind: feature New user-facing feature request or implementation. part: ltac2 Issues and PRs related to the (in development) Ltac2 tactic langauge. labels Feb 10, 2024
@rlepigre

This comment was marked as outdated.

@SkySkimmer

This comment was marked as outdated.

SkySkimmer added a commit to SkySkimmer/coq that referenced this issue Mar 8, 2024
Fix coq#18656

Printing of glb_expr is a bit awkward. We don't have access to the
type so we don't know when we cross an abstraction barrier. OTOH
constructors and projections are not in the environment / nametab so
we still print <abstr> in some places.

The attribute is disabled for open types as the naive implementation
produces not necessarily expected results.
@SkySkimmer SkySkimmer linked a pull request Mar 8, 2024 that will close this issue
SkySkimmer added a commit to SkySkimmer/coq that referenced this issue Mar 14, 2024
Fix coq#18656

Printing of glb_expr is a bit awkward. We don't have access to the
type so we don't know when we cross an abstraction barrier. OTOH
constructors and projections are not in the environment / nametab so
we still print <abstr> in some places.

The attribute is disabled for open types as the naive implementation
produces not necessarily expected results.
SkySkimmer added a commit to SkySkimmer/coq that referenced this issue Apr 26, 2024
Fix coq#18656

Printing of glb_expr is a bit awkward. We don't have access to the
type so we don't know when we cross an abstraction barrier. OTOH
constructors and projections are not in the environment / nametab so
we still print <abstr> in some places.

The attribute is disabled for open types as the naive implementation
produces not necessarily expected results.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind: feature New user-facing feature request or implementation. part: ltac2 Issues and PRs related to the (in development) Ltac2 tactic langauge.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants