<http://canonical.org/~kragen/blosxom.cgi/2002/11/10#ODonnellonEquationalLogicProgramming> > Michael O'Donnell invented equational logic programming languages, > as used by Aardappel and Q.
It'd probably be fairer to say that mathematicians have often attempted equational logic programming languages. AIM-453: > Contrary to popular belief, LISP was not originally derived from > Church's lambda-calculus. ... Early LISP programs were similar to > recursion equations, defining functions on symbolic expressions. > They differed from the equations of pure recursive function theory > by introducting the conditional expression construction to avoid > "pattern-directed invocation". That is, in recursive function > theory one would define the factorial function by the following > two equations: > > factorial(0) = 1 > factorial(successor(x)) = successor(x) * factorial(x) > > In early LISP, however, one would have written: > > factorial[x] = [x=0 -> 1; T -> x*factorial[x-1]] > see also <http://www-formal.stanford.edu/jmc/history/lisp/node2.html> So McCarthy was doing what he could (with the mips that he had) ca. 1960; as Turing was also a mathematician I would be surprised if he had not also thought along similar lines; Kleene certainly did, back in the 1930's. -Dave :::::: Equational logic also underpins what I find to be the "intuition" of simple imperative programming. Glaser et.al. have a list of simple steps to allow novice programmers to avoid freezing up when confronted with a blank page: DSSE-TR-98-7 "Programming by Numbers -- A programming method for novices" Glaser, Hartel, and Garratt > 1. Name the function > 2. Write down its type > 3. Write down the left-hand sides > 4 Deal with any simple case(s) > 5. List the ingredients in preparation for the complex case(s) > 6. Deal with the complex case(s), where some inspirations is required > 7. Think about the result. Note how well the process maps to an ELPL; someone working in an algoly language has also to perform step #3a: code a decision tree which has the left-hand sides from #3 as leaves and variables properly bound for #5. Also, consider how XP maps to Programming by Numbers: making test cases from simple to complex nearly automatically takes care of ordering steps #4-6 (and, if our tests cover well, should take care of step #3); refactoring mercilessly takes care of #7.
