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

Add uninterpreted Map implementation to Prelude.lean #4734

Open
wants to merge 11 commits into
base: develop
Choose a base branch
from

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
pyk/src/pyk/k2lean4/Prelude.lean Outdated Show resolved Hide resolved
pyk/src/pyk/k2lean4/Prelude.lean Outdated Show resolved Hide resolved
@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!

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