Add members to signature #9
Conversation
0de7913 to
965524a
Compare
commit 30aeb16 Author: Jan Mas Rovira <[email protected]> Date: Wed Jul 2 15:41:33 2025 +0200 compiles commit 965524a Author: Jan Mas Rovira <[email protected]> Date: Wed Jul 2 13:30:22 2025 +0200 translation commit 95287e7 Author: Jan Mas Rovira <[email protected]> Date: Mon Jun 30 16:03:28 2025 +0200 wip commit 4c41503 Author: Jan Mas Rovira <[email protected]> Date: Mon Jun 30 15:37:59 2025 +0200 update to v4.21.0 and add mathlib
30aeb16 to
9657be5
Compare
2d29a77 to
4b6e132
Compare
| -- TODO how to do this without tactics? | ||
| {args with data := by { | ||
| rw [x] at memArgs | ||
| apply memArgs }} |
There was a problem hiding this comment.
This is not readable. I don't know what's going on here.
In general, I think we should reduce the number of different AppData types, ideally to one. I added more for type-checking convenience, but maybe we can get rid of this duplication now that we have casts.
There was a problem hiding this comment.
AppData contains: memberId, public fields, arguments. The arguments can have different types depending on memberId, but if we store args type representation in memberId, we can do the casting.
There was a problem hiding this comment.
the above does not require any casting. For some reason lean was unable to typecheck properly without this explicit proof. Maybe there is an easier way to do this, but I didn't know how
There was a problem hiding this comment.
Yes, okay, let's leave it. But I meant something more general: I don't think we need all those different nested AppData types. This gets too complicated. But we can refactor this in a different PR.
There was a problem hiding this comment.
ah yes, I'd like that too. I was often getting confused with the different AppData types
| match mself with | ||
| | none => False | ||
| | (some self) => | ||
| let msomeAppData : Option (Member.SomeAppData sig.pub) := args.data.memberSomeAppData |
There was a problem hiding this comment.
Ah, okay, so now app data can be none and that's what happens in the created case.
This pr introduces
ConstructorIds andMethodIds as part of the signature. The types of their arguments are given in the signature as well.Benefits:
Argsin theAppData.AppData.