Indeed, (functionp (func1 x)) does not imply (functionp x) Sent from ProtonMail mobile -------- Original Message -------- On Jan 1, 2021, 15:12, Andrea Corallo wrote: > "gliao.tw@pm.me" writes: > >> Hi, >> >> More precisely, in this case, the "eshell-find-alias-function" definded in $EMACS_DIR/share/emacs/28.0.50/lisp/eshell/esh-cmd.el.gz seems where the issue pops up. >> >> Before commit #0593f478762437e2a8618f3f874a26424e4590b4, >> >> (eshell-find-alias-function "ls") shows >> >> "eshell/ls" >> >> but on or after commit #0593f478762437e2a8618f3f874a26424e4590b4, the same command shows >> >> "nil" >> >> Both cases are based on functions loaded from eshell.el.gz and esh-cmd.el's corresponding eln files. >> >> It seems that some part of the type inference code added recently lead to this unexpected result. >> >> Thanks, >> Kiong-Ge. > > I see what's going, this is very funny :) > > I've used the alist producing `cl-deftype-satisfies' and reversed it to > get the relation type-predicate -> type. > > But doing this way satisfying `functionp' implies the argument being a > function (while indeed it can be also a symbol). > > Using this information the compiler cleverly proves the output of > `eshell-find-alias-function' being always nil. > > So I guess the relation type <-> predicate in the alist used to build > `cl-deftype-satisfies' is correct but not bijective and cannot simply be > reversed to produce what I use. > > I'll come up with a fix tomorrow. > > Andrea