Skip to content

Add uninterpreted Map implementation to Prelude.lean#4734

Merged
automergerpr-permission-manager[bot] merged 12 commits intodevelopfrom
Lean4Prelude
Jan 20, 2025
Merged

Add uninterpreted Map implementation to Prelude.lean#4734
automergerpr-permission-manager[bot] merged 12 commits intodevelopfrom
Lean4Prelude

Conversation

@JuanCoRo
Copy link
Member

Tackling #4725, this PR adds an uninterpreted implementation for the Map sort.

This PR's goal is to iron out how we want these uninterpreted implementations to be before proceeding with the rest of the hooked functions in domains.md.

@JuanCoRo JuanCoRo requested a review from tothtamas28 January 15, 2025 16:45
@JuanCoRo JuanCoRo self-assigned this Jan 15, 2025
@JuanCoRo JuanCoRo marked this pull request as draft January 15, 2025 16:45
@JuanCoRo
Copy link
Member Author

We can write things like

open MapHookDef
noncomputable def map := mapImpl SortInt SortInt
noncomputable def exmpl : map.map := map.cons 3 4 map.unit

@JuanCoRo JuanCoRo marked this pull request as ready for review January 15, 2025 17:01
@tothtamas28
Copy link
Contributor

In general, I'm fine with any implementation that models the functions over these data types faithfully.

In addition, it should be checked how implementation can be combined with the sort module:

I.e. what additional changes need to be made to the program to make it compile if

inductive SortMap : Type where
  | mk (coll : List (SortKItem × SortKItem)) : SortMap

is replaced by

inductive SortMap : Type where
  | mk (coll : (mapImpl SortKItem SortKItem).map) : SortMap

(assuming that's the intended use).

axiom nodupAx : forall m, List.Nodup (keysAx K m)

-- Uninterpreted Map implementation
noncomputable def mapImpl (K V : Type) : MapHookSig K V :=
Copy link
Contributor

Choose a reason for hiding this comment

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

Would this work as well?

Suggested change
noncomputable def mapImpl (K V : Type) : MapHookSig K V :=
axiom mapImpl : MapHookSig

Copy link
Member Author

Choose a reason for hiding this comment

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

I don't think so since axiom mapImpl : MapHookSig K V doesn't provide concrete elements for mapImpl. So we cannot access it's components like mapImpl.map:

axiom mapImpl : MapHookSig K V
#check mapImpl.map

returns

unknown constant 'MapHookDef.mapImpl.map'

@JuanCoRo
Copy link
Member Author

Re: this comment

Do we want SortMap as an inductive wrapping over the implementation? I thought we would use instead something along these lines:

noncomputable abbrev SortMap := mapImpl KItem KItem

defining SortMap right after KItem or as soon as possible

@tothtamas28
Copy link
Contributor

I thought we would use instead something along these lines:

noncomputable abbrev SortMap := mapImpl KItem KItem

That would be ideal, but I couldn't make the sort module compile that way, so I went with the most straightforward approach for now.

@JuanCoRo
Copy link
Member Author

Ah yes! It seems Lean does not allow (definitions/abbrevs/theorems) and inductives in the same mutual block, just found out!

@automergerpr-permission-manager automergerpr-permission-manager bot merged commit 9be6e60 into develop Jan 20, 2025
18 checks passed
@automergerpr-permission-manager automergerpr-permission-manager bot deleted the Lean4Prelude branch January 20, 2025 13:06
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.

3 participants