Repository navigation
Add uninterpreted Map implementation to Prelude.lean - #4734
Conversation
|
We can write things like open MapHookDef
noncomputable def map := mapImpl SortInt SortInt
noncomputable def exmpl : map.map := map.cons 3 4 map.unit |
|
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)) : SortMapis 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 := |
There was a problem hiding this comment.
Would this work as well?
| noncomputable def mapImpl (K V : Type) : MapHookSig K V := | |
| axiom mapImpl : MapHookSig |
There was a problem hiding this comment.
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.mapreturns
unknown constant 'MapHookDef.mapImpl.map'
|
Re: this comment Do we want noncomputable abbrev SortMap := mapImpl KItem KItemdefining |
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. |
|
Ah yes! It seems Lean does not allow (definitions/abbrevs/theorems) and inductives in the same |
Co-authored-by: Tamás Tóth <tothtamas28@users.noreply.github.com>
Tackling #4725, this PR adds an uninterpreted implementation for the
Mapsort.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.