Skip to main content
Log in

Limited Second-Order Functionality in a First-Order Setting

  • Published:
Journal of Automated Reasoning Aims and scope Submit manuscript

Abstract

We describe how we have defined in ACL2 a weak version of the Common Lisp functional apply, which takes a function and list of actuals and applies the function to the actuals. Our version, called apply$, does not operate on functions but on ordinary objects—symbols and lists representing lambda expressions—some of which are interpreted as functions. We define a syntactic notion of “tameness” to identify the interpretable objects. This makes our apply$ weaker than a true second-order functional but we believe apply$ is powerful enough for many uses in ACL2. To maintain soundness and the conservativity of our Definitional Principle we require that certain hypotheses, called “warrants”, be present in any theorem relying on the behavior of apply$ on non-primitives. Within these constraints we can define “functionals” such as sum and foldr which map tame “functions” over lists and accumulate the results. This allows the ACL2 user to avoid defining specialized recursive functions for each such application. We can prove and use general-purpose lemmas about these “functionals.” We describe the formalization, explain how we keep the Definitional Principle conservative, show examples of useful functions using apply$ and theorems about them, sketch the proof that there is a model of any extension of the system using the new primitives, discuss issues arising in making these functions executable, and show some preliminary performance results.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Price excludes VAT (USA)
Tax calculation will be finalised during checkout.

Instant access to the full article PDF.

Institutional subscriptions

Similar content being viewed by others

Notes

  1. See [19] for a description of the logic and system. For installation instructions and many other resources, see the ACL2 home page [20]. Extensive web-based documentation is available there. In this paper we sometimes refer to documentation by writing “see :DOC \(\textit{x}\),” which means “go to the ACL2 home page [20], click on The User’s Manuals link, then click on the ACL2+Books Manual link and type \(\textit{x}\) into the Jump to box.”

  2. Optional declare forms may be placed before \(\beta \) but we ignore this for the moment.

  3. We use “apply$” instead of “apply” because the latter is the corresponding Common Lisp primitive which is a true functional. Apply$ and apply are equal on “tame” “guard verified” function symbols when the actuals satisfy the “guard” of the function. See Sect. 11.

  4. Formally the symbol F is just obtained from the ASCII code for ‘F’, which is 70, by (intern (coerce (list (code-char 70)) ’string) “ACL2”). The function named f is nowhere to be found!

  5. This could be fixed by complicating our notion of “Expected Behavior” by making it return a list of values but since the vast majority of ACL2 functions return one value we settled for this simple form and await user complaints.

  6. Since apply$ (and every other ACL2 function) is total, problematic uses like (apply$ ’RUSSELL ’(RUSSELL)) are legal terms and thus have some semantic values, but we will not specify what they are.

  7. Because apply$ interprets a LAMBDA object by evaluating the body with ev$ we have to impose restrictions on how ev$ is used to enforce the restrictions on how “functions” are used.

  8. This syntactic rejection of russell can be skirted by defining it to be (defun russell (fn x) (not (apply$ fn (list x x)))). The first formal of the revised russell is classified as a “function.” (Russell ’EQUAL ’EQUAL) behaves as expected because the supplied “functional” argument, ’EQUAL, is a tame function. But (russell ’RUSSELL ’RUSSELL) does not, because the “functional” argument, ’RUSSELL, is not a tame function.

  9. An ACL2 “book” is a file of formal definitions and theorems. Many books contain extensive comments and documentation. Thousands of books contributed by the user community are available via GitHub. A standard way of installing ACL2 from GitHub sources will download the community books so they are available as the subdirectory books/ of your local ACL2 directory. The top of the GitHub directory for ACL2 is https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_acl2_acl2&d=DwIBAg&c=vh6FgFnduejNhPPD0fl_yRaSfZy8CWbWnIf4XJhSqx8&r=r2aSgYn6PHMQXXmeBiKsnvfFG9T9U5fmdQ67xEVmgo0&m=vRrFUnX1Q3Fr5E71n8Ud63k_ILtVVBNdQNbV_UAOm4E&s=NrpdCC6fmnRh_I8oVVLD24qw6YElaOcVQiS7xqUk3eg&e=. The *.lisp files at the top level of that directory are copies of the ACL2 source files from the ACL2 home page [20]. A particular book may be found by clicking your way down the directory hierarchy. For example, to find books/projects/apply-model/apply.lisp start on the GitHub page above and select books, then projects, etc. If the GitHub books were installed with your ACL2 system you can execute an include-book form to load the book into your session. For example, (include-book “projects/apply-model/apply” :dir :system) will load your local copy of projects/apply-model/apply.lisp. Once a book is loaded into your ACL2 session you may inspect definitions, e.g., with (pe ’apply$), and otherwise experiment with it.

  10. Following Common Lisp conventions for dealing with global name conflicts, the archival definition of apply$ in the book books/projects/apply-model/apply.lisp is in its own package (i.e., namespace), “MODAPP” (“model of apply$”). This accomplishes two things. First, it allows the “living” apply$ (which is in the “ACL2” package) to evolve without conflict. Second, it shows that the archival apply$, interesting theorems about it, and example constructions of models of it via “doppelgängers” (described below) making warrants provably valid can all be admitted to ACL2 without relying on any built-in knowledge of the “living” apply$ .

  11. (Caddr \(\textit{args}\)) is a Common Lisp abbreviation for (car (cdr (cdr\(\textit{args}\)))).

  12. Functions that satisfy all the requirements imposed by apply$ except for the requirement that they return single values have badges in which this component is NIL. Even though apply$ cannot behave as expected on such symbols, the corresponding multiple-valued function might be used in the definition of a single-valued function and we need to track the argument use of the multiple-valued function to determine whether the single-valued function is acceptable. We could allow apply$ to handle multiple-valued functions by complicating the “Expected Behavior” guideline but we have chosen not to.

  13. ACL2 imposes additional restrictions on its lambda objects, but the LAMBDA objects we are dealing with here are just objects being used as data by apply$ and ev$.

  14. These kinds of problems can be partially addressed with macros that introduce the required recursive functions and prove the indicated lemmas about them; for example see :DOC deflist and :DOC defdata. In our opinion this is not as elegant as introducing the scion itself as a function that can be directly named and used.

  15. Inspection of the script in projects/apply-model/report.lisp reveals that we do not use the macro “+” in the LAMBDA object but use its expansion into a function of two arguments, binary-+, because ev$ cannot handle macros. We similarly abbreviate the LAMBDA objects in T9 and T11 below.

  16. One might be tempted to allow LAMBDA objects containing free variables whose values are determined by the lexical environment. But then apply$ would not be definable as a function. Consider (apply$ ’(LAMBDA (X) PARAMS) ’(1)). The arguments to apply$ are constants, so if apply$ is a function, the value must be a constant regardless of the lexical environment.

  17. The reader should be aware that our various example definition files are not always compatible. For example, we may define a scion named sum in one file and place its :FN formal as the first formal, and then in another example file define sum so that its :FN formal is the second one.

  18. Actually, if a G1 function, g, is ancestrally dependent on badge or the tamep functions, we do introduce its doppelgänger, \({{{\texttt {\textit{g!}}}}}\), that instead calls doppelgängers. To see an example of this, look at ok-fnp in books/projects/apply-model/ex2/user-defs.lisp and its doppelgänger, ok-fnp! in books/projects/apply-model/ex2/doppelgängers.lisp.

  19. For G1 functions with doppelgängers, i.e., those dependent on badge, tamep, etc, it calls the doppelgänger.

  20. Indeed, except for a relatively small amount of Common Lisp boot-strapping code, ACL2 is written in itself.

  21. In future work, we may explore the use of conditional rewrite rules instead.

References

  1. Andrews, P.B., Brown, C.E.: TPS: a hybrid automatic-interactive system for developing proofs. J. Appl. Log. 4(4), 367–395 (2006)

    Article  MathSciNet  Google Scholar 

  2. Beeson, M.: Otter-lambda, a theorem-prover with untyped lambda-unification. In: Sutcliffe, G., Schulz, S., Tammet, T. (eds.) Proceedings of the ESFOR Workshop at IJCAR 2004 (2004)

  3. Benzmüller, C., Sultana, N., Paulson, L.C., Theiß, F.: The higher-order prover LEO-II. J. Autom. Reason. 55(4), 389–404 (2015)

    Article  MathSciNet  Google Scholar 

  4. Bertot, Y., Castran, P.: Interactive Theorem Proving and Program Development: Coq’Art: The Calculus of Inductive Constructions, 1st edn. Springer, Berlin (2010)

    Google Scholar 

  5. Blanchette, J.C., Kaliszyk, C., Paulson, L.C., Urban, J.: Hammering towards QED. J. Formaliz. Reason. 9(1), 101–148 (2016)

    MathSciNet  MATH  Google Scholar 

  6. Boyer, R., Moore, J.S.: The addition of bounded quantification and partial functions to a computational logic and its theorem prover. J. Autom. Reason. 4(2), 117–172 (1988)

    Article  MathSciNet  Google Scholar 

  7. Boyer, R.S., Moore, J.S.: A Computational Logic Handbook, 2nd edn. Academic Press, New York (1997)

    MATH  Google Scholar 

  8. Boyer, R.S., Goldschlag, D.M., Kaufmann, M., Moore, J.S.: Functional instantiation in first-order logic. In: Lifschitz, V. (ed.) Artificial Intelligence and Mathematical Theory of Computation: Papers in Honor of John McCarthy, pp. 7–26. Academic Press, London (1991)

    Chapter  Google Scholar 

  9. Brock, B., Kaufmann, M., Moore, J.S.: Rewriting with equivalence relations in ACL2. J. Autom. Reason. 40(4), 293–306 (2008)

    Article  MathSciNet  Google Scholar 

  10. Brown, C.E.: Satallax: an automatic higher-order prover. In: Automated Reasoning: 6th International Joint Conference, IJCAR 2012, Manchester, UK, 26–29 June 2012. Proceedings, pp. 111–117 (2012)

  11. Chamarthi, H., Dillinger, P.C., Manolios, P.: Data definitions in the ACL2 sedan. In: ACL2 ’14, pp. 27–48. EPTCS (2014)

    Article  Google Scholar 

  12. Goel, S., Hunt, W.A., Kaufmann, M.: Simulation and formal verification of x86 machine-code programs that make system calls. In: Claessen, K., Kuncak, V. (eds.) FMCAD’14: Proceedings of the 14th Conference on Formal Methods in Computer-Aided Design, pp. 91–98. EPFL, Switzerland (2014)

  13. Goel, S.: Formal verification of application and system programs based on a validated x86 ISA model. Ph.D. thesis, University of Texas at Austin (2016)

  14. Gordon, M.J.C.: On the power of list iteration. Comput. J. 22(4), 376–379 (1979)

    Article  MathSciNet  Google Scholar 

  15. Gordon, M.J.C., Melham, T.F. (eds.): Introduction to HOL: A Theorem Proving Environment for Higher Order Logic. Cambridge University Press, New York (1993)

    MATH  Google Scholar 

  16. Greve, D., Kaufmann, M., Manolios, P., Moore, J.S., Ray, S., Ruiz-Reina, J.L., Sumners, R., Vroon, D., Wilding, M.: Efficient execution in an automated reasoning environment. J. Funct. Program. 18(01), 15–46 (2008)

    Article  Google Scholar 

  17. Hunt Jr., W.A., Kaufmann, M., Moore, J.S., Slobodova, A.: Industrial hardware and software verification with ACL2. In: Gardner, P., O’Hearn, P., Gordon, M., Morrisett, G., Schneider, F.B. (eds.) Verified Trustworthy Software Systems. Philosophical Transactions A, vol. 374. Royal Society Publishing (2017). https://doi.org/10.1098/rsta.2015.0399

    Article  Google Scholar 

  18. Kaufmann, M.: Trusted extension of ACL2 system code: towards an open architecture. In: Workshop on Trusted Extensions of Interactive Theorem Provers (2010). See https://urldefense.proofpoint.com/v2/url?u=http-3A__www.cs.utexas.edu_users_&d=DwIBAg&c=vh6FgFnduejNhPPD0fl_yRaSfZy8CWbWnIf4XJhSqx8&r=r2aSgYn6PHMQXXmeBiKsnvfFG9T9U5fmdQ67xEVmgo0&m=vRrFUnX1Q3Fr5E71n8Ud63k_ILtVVBNdQNbV_UAOm4E&s=NXMiBg4nq_C3pnEnk6Tdql75ei8JA-JX02usDOKVdmM&e=kaufmann/itp-trusted-extensions-aug-2010/. Accessed 2018

  19. Kaufmann, M., Manolios, P., Moore, J.S.: Computer-Aided Reasoning: An Approach. Kluwer Academic Press, Boston (2000)

    Book  Google Scholar 

  20. Kaufmann, M., Moore, J.S.: The ACL2 home page. In: Department of Computer Sciences, University of Texas at Austin (2018). https://urldefense.proofpoint.com/v2/url?u=http-3A__www.cs.utexas.edu_users_moore_acl2_&d=DwIBAg&c=vh6FgFnduejNhPPD0fl_yRaSfZy8CWbWnIf4XJhSqx8&r=r2aSgYn6PHMQXXmeBiKsnvfFG9T9U5fmdQ67xEVmgo0&m=vRrFUnX1Q3Fr5E71n8Ud63k_ILtVVBNdQNbV_UAOm4E&s=gWfwZpi-faeBogx3pJCo6I5MQjZlJlpVPXbBI0MGPUQ&e=. Accessed 2018

  21. Kaufmann, M., Moore, J.S.: ACL2 User Community: ACL2 sources and ACL2 community books on GitHub. In: GitHub (2018). https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_acl2_acl2&d=DwIBAg&c=vh6FgFnduejNhPPD0fl_yRaSfZy8CWbWnIf4XJhSqx8&r=r2aSgYn6PHMQXXmeBiKsnvfFG9T9U5fmdQ67xEVmgo0&m=vRrFUnX1Q3Fr5E71n8Ud63k_ILtVVBNdQNbV_UAOm4E&s=NrpdCC6fmnRh_I8oVVLD24qw6YElaOcVQiS7xqUk3eg&e=. Accessed 2018

  22. Kunčar, O.: Correctness of Isabelle’s cyclicity checker: implementability of overloading in proof assistants. In: Proceedings of the 2015 Conference on Certified Programs and Proofs, CPP ’15, pp. 85–94, New York, NY, USA. ACM (2015)

  23. McCarthy, J.: Recursive functions of symbolic expressions and their computation by machine (part I). CACM 3(4), 184–195 (1960)

    Article  Google Scholar 

  24. McCune, W.: Otter 3.0 reference manual and guide. Technical report ANL-94/6, Argonne National Laboratory, Argonne, IL (1994). See also https://urldefense.proofpoint.com/v2/url?u=http-3A__www.mcs.anl.gov_AR_otter_&d=DwIBAg&c=vh6FgFnduejNhPPD0fl_yRaSfZy8CWbWnIf4XJhSqx8&r=r2aSgYn6PHMQXXmeBiKsnvfFG9T9U5fmdQ67xEVmgo0&m=vRrFUnX1Q3Fr5E71n8Ud63k_ILtVVBNdQNbV_UAOm4E&s=bQ9nItKqAZKGDoFo__COKKQuPtL-9Qhqa7CZa4HLPgg&e=. Accessed 2018

  25. Meng, J., Paulson, L.C.: Translating higher-order clauses to first-order clauses. J. Autom. Reason. 40(1), 35–60 (2008)

    Article  MathSciNet  Google Scholar 

  26. Meseguer, J.: Twenty years of rewriting logic. J. Log. Algebr. Program. 81(7), 721–781 (2012)

    Article  MathSciNet  Google Scholar 

  27. Paulson, L.C.: ML for the Working Programmer. Cambridge University Press, New York (1991)

    MATH  Google Scholar 

  28. Paulson, L.C.: Isabelle: A Generic Theorem Prover. LNCS 828. Springer, Berlin (1994)

    Book  Google Scholar 

  29. Pitman, K.: The common lisp HyperSpec. See https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lispworks.com_documentation_common-2Dlisp&d=DwIBAg&c=vh6FgFnduejNhPPD0fl_yRaSfZy8CWbWnIf4XJhSqx8&r=r2aSgYn6PHMQXXmeBiKsnvfFG9T9U5fmdQ67xEVmgo0&m=vRrFUnX1Q3Fr5E71n8Ud63k_ILtVVBNdQNbV_UAOm4E&s=_Wd_KHgA45uc-8RythKrUZF9qgc-wNTUA3k7JyZh1zE&e=.html. Accessed 2018

  30. Reynolds, J.C.: Definitional interpreters for higher-order programming languages. High. Order Symbol. Comput. 11(4), 363–397 (1998)

    Article  Google Scholar 

  31. Steele Jr., G.L.: Common Lisp the Language, 2nd edn. Digital Press, Burlington (1990)

    MATH  Google Scholar 

  32. The Haskell home page. https://urldefense.proofpoint.com/v2/url?u=https-3A__www.haskell.org&d=DwIBAg&c=vh6FgFnduejNhPPD0fl_yRaSfZy8CWbWnIf4XJhSqx8&r=r2aSgYn6PHMQXXmeBiKsnvfFG9T9U5fmdQ67xEVmgo0&m=vRrFUnX1Q3Fr5E71n8Ud63k_ILtVVBNdQNbV_UAOm4E&s=MIT0gLXrGfuoJ3pMHEAFlrqshodFFiClh_eQ8wpP7FA&e=. Accessed 2018

Download references

Acknowledgements

We thank the reviewers for their helpful suggestions. We thank ForrestHunt, Inc., for its support of the ACL2 Project in general and this work in particular. We also would like to acknowledge Mike Gordon, whose support for higher-order logic never diminished his enthusiasm for our first-order provers and with whom we shared many hours of interesting and enlightening conversations.

Author information

Authors and Affiliations

Authors

Corresponding author

Correspondence to J Strother Moore.

Additional information

Publisher's Note

Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Rights and permissions

Reprints and permissions

About this article

Check for updates. Verify currency and authenticity via CrossMark

Cite this article

Kaufmann, M., Moore, J.S. Limited Second-Order Functionality in a First-Order Setting. J Autom Reasoning 64, 391–422 (2020). https://doi.org/10.1007/s10817-018-09505-9

Download citation

  • Received:

  • Accepted:

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s10817-018-09505-9

Keywords

Navigation