Closed dselsam closed 3 years ago
What about erasing auto_param
? That is, the porting tools rewrites auto_param a t
==> a
.
I agree that would be better than not aligning and keeping the unreadable junk. I think the auto-param is useful information though, and figured mathlib might reimplement it and want the old annotations. We could also only auto-port the string literals used in auto-param and discard whatever breaks because of that change, which is probably nothing besides the auto_param
equations themselves.
I added special support for replacing auto_param
calls with autoParam
calls inside mathport
. I think every auto_param
in mathlib uses obviously
, and so for now I just hard-coded syntax for Mathlib.obviously
in the new autoParam
terms rather than parse the names.
There are more than just obviously
. Here's what I found (this should be an exhaustive list):
Whoops, I had a buggy grep query. Good catch, thanks. I guess I will decode the names during mathport.
Now we decode the concrete strings from auto_param
arguments: https://github.com/dselsam/mathport/blob/master/MathPort/Translate.lean#L63
Even though strings are only used for meta-programming, the misalignment is unpleasant since e.g. every
auto_param
prints as an enormous term of unreadablestring.str
applications. There are four issues here:fin
vsFin
(def vs structure)unsigned
vsUInt32
(def vs structure)is_valid_char
vsisValidChar
(Nat.le issue as in https://github.com/dselsam/mathport/issues/15)The last two issues need to be solved independently. The first two seem to only be required for aligning strings.
Note: lean3 used to make
fin
a structure but changed it to a def so that thesubtype
API could be used: https://github.com/leanprover-community/lean/issues/359I see a few options:
Fin
fin4
that is only used for characters, and align thischar
->Char
anyway and discard whatever downstream declarations failFin
as defI suggest backporting
fin4
(just forchar
) as a default, assuming Leo wants to keepFin
a structure.